IT-Berufe-Podcast

Um den Umgang mit Fehlern in der Projektdokumentation in der Projektpräsentation und im Fachgespräch geht es in der zwölften Episode der Shorts des IT-Berufe-Podcasts.

Wenn dir nach Abgabe deiner Projektdokumentation Fehler auffallen, solltest du in der Projektpräsentation immer mit der korrigierten Version arbeiten und größere inhaltliche Fehler offen, aber knapp ansprechen. Triviale Formfehler wie Rechtschreibung oder Kommas musst du nicht thematisieren. Entscheidend ist ein professioneller Umgang: Fehler nicht leugnen oder ignorieren, sondern zeigen, was du daraus gelernt hast, wie du sie korrigiert hast und welche Folgen sie für das Projekt haben.

Inhalt

Umgang mit Fehlern nach Abgabe der Projektdokumentation

Wenn dir nach der Abgabe deiner Projektdokumentation noch Fehler auffallen, gilt grundsätzlich: korrigieren statt ignorieren. Kleine formale Fehler musst du nicht extra erwähnen, größere inhaltliche Fehler solltest du dagegen offen und professionell behandeln.

Grundidee

Die Projektdokumentation, die Projektpräsentation und das Fachgespräch sind getrennte Prüfungsleistungen. Deshalb solltest du Fehler aus der Doku nicht einfach in die Präsentation übernehmen, nur weil die Doku schon abgegeben ist. In der Präsentation solltest du immer die korrigierte Fassung zeigen.

Wichtig ist dabei:

Fehler offen ansprechen, wenn sie relevant sind

keinen großen Fokus auf die Fehler legen

zeigen, wie du den Fehler erkannt und behoben hast

deutlich machen, was du daraus gelernt hast

Warum Fehler oft erst später auffallen

Zwischen Abgabe der Dokumentation und Präsentation oder Fachgespräch liegen oft mehrere Wochen. In dieser Zeit bereitest du deine Präsentation vor und schaust dir Inhalte wie Kostenrechnung, Amortisation, Diagramme oder Projektplanung nochmal an. Dabei kann dir auffallen, dass etwas falsch gerechnet, unvollständig oder inhaltlich nicht mehr passend ist.

Welche Fehler du ignorieren kannst

Triviale formale Fehler musst du nicht ansprechen. Dazu gehören z.B.:

Rechtschreibfehler

fehlende Kommas

falsche Seitenzahlen

kleinere Verweisfehler

Solche Kleinigkeiten führen nicht dazu, dass du durchfällst, und sind in der Präsentation nicht relevant.

Welche Fehler du korrigieren und ggf. ansprechen solltest

Relevant sind inhaltliche Fehler, also alles, was Auswirkungen auf das Projekt oder die Bewertung haben kann. Beispiele aus dem Text sind:

Rechenfehler in der Kosten- oder Amortisationsrechnung

Fehler in der Zeit- oder Ressourcenplanung

vergessene Arbeitsstunden von Mitarbeitenden

falsche oder nicht mehr passende technische Entscheidungen

fehlende oder falsche Diagramme

geplante, aber nicht umgesetzte Features

Solche Fehler können zu einer anderen Einschätzung des Projekts führen. Deshalb solltest du sie professionell behandeln.

Professioneller Umgang mit Fehlern

Fehler zu machen ist normal, auch in echten IT-Projekten. Entscheidend ist nicht, dass nie etwas schiefläuft, sondern wie du damit umgehst. Genau das ist auch in der Prüfung relevant.

Ein professioneller Umgang bedeutet:

den Fehler erkennen

einschätzen, wie schwerwiegend er ist

überlegen, ob und wie er korrigiert werden kann

die Auswirkungen auf das Projekt benennen

erklären, wie du solche Fehler künftig vermeiden willst

Das entspricht auch dem Verhalten im Berufsalltag. Wer merkt, dass sich ein Projekt später amortisiert oder länger dauert, darf das nicht verschweigen.

Was in die Präsentation gehört

In der Projektpräsentation solltest du nur dann auf einen Fehler eingehen, wenn er für die gezeigten Inhalte relevant ist.

Kleine Auswirkungen

Wenn sich durch einen Rechenfehler am Ergebnis praktisch nichts ändert, kannst du in der Präsentation einfach die korrigierte Version zeigen und den Fehler kurz mit einem Nebensatz erwähnen.

Beispiel aus dem Text:

Die Amortisation verschiebt sich nur um wenige Monate.

Die Entscheidung für das Projekt bleibt trotzdem gleich.

Dann reicht ein kurzer Hinweis, dass die Rechnung in der Doku leicht falsch war, das Endergebnis aber unverändert bleibt.

Größere Auswirkungen

Wenn ein Fehler deutliche Folgen hat, solltest du ihn klar benennen. Das kann z.B. sinnvoll sein, wenn:

das Projekt sich gar nicht mehr amortisiert

mehrere Features nicht umgesetzt wurden

sich wesentliche Projektentscheidungen ändern

Dann kann es sogar sinnvoll sein, dafür eine eigene Folie einzuplanen und nachvollziehbar zu erklären:

was anders gelaufen ist als geplant

warum das passiert ist

welche Konsequenzen das hatte

wie du damit umgegangen bist

Was du nicht tun solltest

Unprofessionell wäre es,

einen bekannten Fehler absichtlich in der Präsentation zu wiederholen

Fehler zu ignorieren

Fehler zu leugnen

lange auf Fehlern herumzureiten

in der Präsentation Fehler anzusprechen, die dort gar nicht vorkommen

Wenn ein fehlerhaftes Diagramm in der Präsentation gar nicht gezeigt wird, musst du es dort auch nicht thematisieren. Du sollst dich nicht unnötig schlechter machen.

Vorbereitung auf das Fachgespräch

Auch wenn du einen Fehler in der Präsentation nicht ansprichst, solltest du dich auf Fragen dazu im Fachgespräch vorbereiten. Mindestens ein Teil des Prüfungsausschusses hat die Doku gelesen und könnte den Fehler gefunden haben.

Dann ist eine gute Reaktion z.B.:

den Fehler bestätigen

sagen, dass er inzwischen erkannt und korrigiert wurde

die Auswirkungen kurz erklären

So kann es sein, dass du in der Doku für den Fehler einen Punkt verlierst, im Fachgespräch aber einen positiven Eindruck hinterlässt, weil du professionell damit umgehst.

Besonderheit beim Prüfungsausschuss

Nicht alle Prüfenden haben deine Dokumentation zwingend gelesen. In vielen Ausschüssen wird die Arbeit aufgeteilt. Deshalb gilt für die Präsentation generell:

geh nicht davon aus, dass alle deine Doku kennen

erkläre dein Projekt so, dass auch neue Zuhörende folgen können

verschwende keine Präsentationszeit mit langen Fehlererklärungen

Gerade deshalb solltest du Fehler nur kurz und zielgerichtet ansprechen.

Einfluss auf die Note

Ein einzelner Fehler führt normalerweise nicht dazu, dass du durchfällst. Das Projekt wird als Gesamtleistung bewertet. Auch mit kleineren oder sogar größeren Fehlern kannst du noch eine gute oder sehr gute Note erreichen.

Kritisch wird es eher dann, wenn du unprofessionell reagierst, also z.B.:

Fehler bewusst verschweigst

sie abstreitest

Ausreden suchst

Zentrale Kernaussage

Wenn dir nach der Abgabe Fehler auffallen:

bleib ruhig

korrigiere inhaltliche Fehler

zeige in der Präsentation immer die richtige Version

sprich relevante Fehler kurz und offen an

bereite dich auf Nachfragen im Fachgespräch vor

zeige, was du daraus gelernt hast

Vorbeugung vor der Abgabe

Am besten ist es natürlich, Fehler schon vor der Abgabe zu vermeiden. Dafür kann es helfen, die Doku vor dem Einreichen noch einmal von anderen gegenlesen zu lassen, z.B. durch:

dein:e Ausbilder:in

andere Personen im Umfeld

ein geeignetes KI-Tool für Rechtschreibung und Kommasetzung

Das Optimum ist immer der Fehler, den du gar nicht erst machst.

Links

Permalink zu dieser Podcast-Episode

RSS-Feed des Podcasts

Transkription der gesamten Episode

Automatisch erzeugte Transkription der Episode

[0:20] Heute geht es um ein Thema, was wirklich sehr häufig gefragt wird, und zwar bezüglich der beiden Prüfungsleistungen, Projektdokumentation und Projektpräsentation und Fachgespräch. Wie soll ich damit umgehen, wenn ich in meiner Projektdokumentation Fehler finde, und zwar nachdem ich sie abgegeben habe? Soll ich das in der Projektpräsentation ansprechen? Soll ich die korrigieren? Soll ich darauf hinweisen? Soll ich das ignorieren? Soll ich es leugnen? Wie gehe ich mit Fehlern in der Doku um, nachdem die Doku abgegeben ist. Und es kommen dann ja noch zwei Prüfungsleistungen, nämlich die Präsentation und das Fachgespräch, wie gerade auch schon gesagt. Und es gibt ja verschiedene Möglichkeiten, wie ich mit diesen Fehlern umgehen kann. Und wie man am besten damit umgeht, ich würde erst mal sagen, wir fangen wieder mit dem Too Long den Read an. Ich würde sagen, immer korrigieren. Wenn dir Fehler auffallen, korrigiere sie im Nachhinein. Trivialitäten auf jeden Fall einfach stillschweigend sogar korrigieren. Und große Sachen explizit aber ansprechen, wenn sie irgendwie wichtig fürs Projekt sind und krass andere Entscheidungen zur Folge hätten oder das Projekt auf einmal drei Jahre länger braucht, um sich zu automatisieren oder Sonstiges.

[1:23] Das würde ich auf jeden Fall ansprechen, aber keinen Fokus auf die Fehler legen. Projektpräsentation und Fachgespräch sind separate Prüfungsleistungen. Die haben zwar mit dem gleichen Thema zu tun, nämlich dein Projekt, aber die Projektpräsentation ist eine eigenständige Prüfungsleistung, unabhängig von der Doku. Also auch wenn du der Doku durchfällst, mal als Beispiel, könntest du eine Projektpräsentation bestehen, weil das sind halt zwei getrennte Prüfungsleistungen. Also, kurz gesagt, sprich die Fehler an, geh offen damit um, kommuniziere das und sag, dass du was gelernt hast, aber leg nicht den Fokus auf die Fehler. Und was ich jetzt genau damit meine, da gehen wir jetzt in den nächsten Minuten drauf ein. Fangen wir mal vorne an. Um was für Fehler soll es heute überhaupt gehen und warum kann und darf oder muss man die überhaupt korrigieren? Ich glaube, das Zweite ist einfacher zu beantworten. Zwischen der Abgabe der Dokumentation und der Projektpräsentation und Fachgespräch liegen bei vielen Prüflingen tatsächlich mehrere Wochen. Also jetzt mal nur als Beispiel. Ich nehme das gerade 2026 auf. Da war die Prüfung Ende April und zum Beispiel bei meiner IHK war dann eine Woche später die Abgabe. Also Anfang Mai musste man die Projektdokumentation abgeben.

[2:28] Die Fachgespräche und Projektpräsentationen gehen aber bis Ende Juni. Das heißt, fast zwei Monate liegen eventuell dazwischen, zwischen Abgabe der Doku und dem mündlichen Prüfungstermin. Und in anderen Bundesländern, das richtet sich ja oft auch nach den Schulferien, wann die anfangen. Es sind ja auch immer Lehrer und Lehrerinnen mit im Prüfungsausschuss. Und die werden natürlich nur in den Schulzeiten eingesetzt. Das heißt, je nachdem, wann die Ferien starten, kann das halt noch später sein oder eben auch früher. Das kommt halt ganz auch so ein bisschen aus dem Bundesland an. Und natürlich auch noch auf die IHK die Räumlichkeiten haben muss, etc. Also eine Terminplanung mit so vielen Prüfenden und Prüflingen ist grundsätzlich sehr schwierig. Aber bei vielen Prüflingen wird es so sein, dass, ich sage mal, mehrere Wochen zwischen Projektdokumentation, Abgabe und den anderen beiden Prüfungen an Prüfungsleistungen liegen werden. So, und das kann natürlich dann sein, dass man in diesen Wochen nochmal auf sein Projekt schaut, vielleicht um die Projektpräsentation vorzubereiten. Überraschung. Da guckt man sich vielleicht die Sachen nochmal an. Da kommen ja auch wichtige Inhalte nochmal in die Präsi. sowas wie eine Kostenrechnung, Amortisation, irgendwelche Diagramme, die gezeichnet wurden, eine Projektplanung, eine Zeitplanung, etc. Das gehört natürlich auch alles in die Präsi. Habe ich schon genug Podcast-Debison zu gemacht zu dem Thema. Da guckt man sich dann vielleicht nochmal an, was habe ich eigentlich in der Doku da geschrieben? Vielleicht weiß man das nicht mehr auswendig, weil es schon ein paar Wochen her ist.

[3:41] Und dann stellt man fest, oh, da habe ich mich ja irgendwie verrechnet oder oh, das stimmt ja gar nicht oder ich habe ja gar nicht Framework X genommen, sondern inzwischen Y oder weiß der Geier was.

[3:50] Und jetzt ist die Frage, wie gehe ich dann mit solchen Sachen um? Und fangen wir mal mit den kleinen Fehlerchen an. So, ich habe irgendwo ein Komma vergessen oder ein Rechtschreibfehler oder Sonstiges. Das ist natürlich völlig… Es ist sinnfrei, das zu erwähnen. Ja, das kann jedem mal passieren. Selbst nach der Abgabe kann man auf der Titelseite noch einen Rechtsstaatfehler finden. Das habe ich auch schon oft genug gesehen. Also niemand, kein Mensch ist fehlerfrei und deswegen wirst du jetzt auch nicht durchfallen oder eine Note oder geschweige denn vielleicht nur einen Punkt abgezogen bekommen, weil irgendwo mal ein Komma fehlt. Also wenn wir das machen würden, dann würden reihenweise Leute durch die Prüfung fallen und das passiert nicht.

[4:23] Also solche Sachen sind, ich nenne die jetzt mal triviale Fehler oder es ist irgendwo, keine Ahnung, ein Verweis nicht richtig und eine Seitenzahl stimmt nicht oder sowas. Solche Trivialitäten interessieren natürlich keinen Menschen in der Projektpräsentation, da brauchst du gar nicht drauf hinweisen. Und das würde ich auch nicht ansprechen oder so. Das ist einfach, ja, ist passiert, fertig. Im Zweifel fällt das noch nicht mal im Prüfenden auf, dass irgendwo ein Komma fehlt. Also von daher, das ignorieren wir einfach. Aber wenn du jetzt solche Sachen gemacht hast, wie ich gerade schon gesagt habe, Kosten, eine Amortisationsrechnung zum Beispiel, du hast irgendwo falsch summiert Oder du hast irgendwo eine falsche Rechnung gemacht, hast falsche Zahlen benutzt oder so. Und dann stellt sich heraus, oh, das Projekt amortisiert sich doch erst drei Monate später und nicht nach dem ursprünglich ausgerechneten Termin oder so etwas. Oder du hast, keine Ahnung, ein Diagramm gezeichnet, was gar nicht zur Realität passt oder du hast dich irgendwo vertan. Oder, keine Ahnung, es gibt, sag ich mal, inhaltliche Fehler, die sich auch auf das Projekt auswirken. Da sehen die Oberflächen auf einmal anders aus, wie du bauen solltest. Oder das Projekt hat ein gewisses Feature gar nicht, was du eigentlich eingeplant hast. oder, keine Ahnung, statt drei Firewalls brauchst du doch nur zwei oder.

[5:23] Alles, was halt wirklich sich inhaltlich auf das Projekt bezieht, davon rede ich jetzt, wenn ich Fehler korrigieren sage. Alles andere formale Fehler wie Rechtschreibung etc. Kannst du auf jeden Fall ignorieren. Aber irgendwas, was vielleicht zu einer unterschiedlichen Einschätzung im Projekt geführt hätte, bei dir und auch bei den Prüfenden. Also zum Beispiel, wie gesagt, Rechenfehler, Planungsfehler in der Zeitplanung. Du hast Ressourcen vergessen, einen zu planen. Arbeitsstunden von Mitarbeitenden hast du nicht eingeplant. Zum Beispiel, da habe ich schon so oft gesehen, da schreibt jemand in seinem Text bei einem Anwendungsermittlungsprojekt, ja, ein Kollege hat noch drei Stunden ein Code-Review gemacht. Und dann gucke ich in die Kostenplanung und stelle fest so, hä, wo sind denn diese drei Stunden? Die tauchen da gar nicht auf. So sind einfach vergessen worden. Aber je nach Stundensatz macht das halt vielleicht mal 200 Euro schon aus insgesamt, wenn jemand drei Stunden auf so ein Projekt drauf guckt. Und das wurde einfach nicht mit eingeplant. Und das führt dann dazu, dass natürlich, wenn ich die Amortizierungsrechnung mache, das Ding sich später amortisiert, weil ich Kosten vergessen habe. Ganz einfach. Solche Sachen. Oder ich habe vielleicht bestimmte Frameworks, habe ich gerade schon mal angesprochen, benutzt, die sich inzwischen aber überholt haben, die ich gar nicht wirklich verwendet habe. Oder ich habe es anders gelöst. Oder ich habe vergessen, ein Diagramm einzufügen, was ich eigentlich gemalt habe. So, keine Ahnung. Ahnungsermittlung wieder beim Klassiker. Use-Case-Diagramm habe ich eigentlich erstellt. Ist aber gar nicht in der Doku zum Beispiel. Solche Sachen. Da ist jetzt die Frage, wie gehe ich damit um? Und grundsätzlich, habe ich ja gerade schon gesagt, jeder Mensch macht Fehler. Also erstmal Ruhe bewahren. Du fällst jetzt wegen einem Fehlerchen nicht durch die Prüfung. Klar, eventuell gibt es einen Punktabzug.

[6:51] Aber wahrscheinlich wird das nicht dazu führen, dass du jetzt hier ein arge Bedrängnis bekommst, nur weil du da irgendwo einen kleinen Inhalt mal vergessen hast oder so. Das kann halt passieren. Wir sind alle nur Menschen. So, jetzt ist aber die Frage, wie gehst du professionell mit diesem Fehler um? Und das ist ja auch etwas, was wir in der Prüfung auf jeden Fall bewerten. Wir gucken ja nicht nur darauf, dass du eine schöne Rechtschreibung hast, sondern vor allem geht es darum, wie sieht inhaltlich dein Projekt aus? Hast du das vernünftig geplant? Hat das einen passenden Umfang? Zeig das alles das, was du als Abschlussprüfung zeigen musst. Hast du alles gelernt, was für deinen Beruf wichtig war? Und dazu gehört natürlich auch eine Planung, eine Kostenkalkulation, Amortisation etc. Aber natürlich, auch in der Realität, können natürlich in Projekten Fehler passieren. Da wurde irgendwie was falsch geplant oder man hat sich verschätzt oder stellt sich raus, oh, mitten im Projekt gibt es eine neue Java-Version und ich muss hochziehen oder was auch immer. Und auf einmal passt alles von und hin nicht mehr. Das ist ja normal. Ich glaube nicht, dass es in der Realität irgendein Projekt gibt, was 100% so funktioniert, wie es geplant wurde. Das gibt es nicht. Und dann zeigt sich ja der Unterschied zwischen guten und schlechten Prüflingen darin, wie sie denn damit umgehen, mit solchen gefundenen Fehlern. Und das ist dann demnach eigentlich auch Teil der Prüfungsleistung, wenn so ein Fehler passiert, dass du vernünftig damit umgehst und dann genau wie im echten Leben auch überlegst, was wäre jetzt sinnvoll? Soll ich diesen Fehler einfach stillschweigend ignorieren und meinem Chef nicht sagen, dass sich das Projekt doch erst ein Jahr später amortisiert?

[8:14] Das wäre für die Realität auch keine gute Idee. Denn wenn der Chef dann irgendwann merkt, eigentlich hätten wir schon Kohle einnehmen müssen, aber ist noch nichts auf dem Konto. Was ist da los? Dann wird er ja auch zu dir kommen oder sie und sagen, was hast du denn da gemacht? Und dann ist natürlich uncool zu sagen, ach ja, das wusste ich zwar, aber ich habe es dir nicht gesagt, lieber Chef. Das ist gar keine gute Idee. Ja. Wenn wir mal überlegen, wie es in der Realität ist, du, keine Ahnung, du machst ein Projekt zum Einstieg und jemand anderes wartet darauf, dass du fertig bist und kann dann darauf aufbauend weitermachen, dann kannst du ja auch nicht einfach schweigen und sagen, ach ja, ich brauche zwar zwei Wochen länger, aber ich sage es keinem. Weil die Leute warten ja darauf. Und je früher du weißt, dass etwas zum Beispiel später fertig wird, desto früher musst du es auch weitergeben an die Leute, die darauf warten. Weil sonst verzögert sich alles Weitere und die Leute werden unruhig, das ganze Projekt wird vielleicht verschoben etc. Das können wir auf gar keinen Fall machen. Das heißt, wenn dir was auffällt, kommunizieren. So ist es in der Realität und so erwarten wir es auch in der Projektarbeit. Und wenn dir jetzt im Nachhinein ein Fehler auffällt, dann ist es sinnvoll, damit vernünftig umzugehen, zu sagen, ja, ich habe hier einen Fehler gemacht, ich habe das erkannt.

[9:18] Und nicht einfach, ja, ich habe es erkannt, Ende. Sondern viel wichtiger ist jetzt natürlich, was mache ich denn jetzt damit? Also vielleicht eine erste Einschätzung. War das ein schlimmer Fehler? Kann ich den korrigieren? Wenn ja, wie habe ich den korrigiert? Oder war das etwas, das ich gar nicht korrigieren kann, was so schlimm ist, dass das ganze Projekt jetzt auf einmal scheitert? Das ist natürlich blöd in so einer Abschlussprüfung, aber theoretisch könnte das ja auch passieren. Aber dann kannst du trotzdem immer noch die Prüfung bestehen. Ich mache nochmal eine andere Episode dazu, ob das Abschlussprojekt erfolgreich sein muss. Und Spoiler, nein, muss es nicht. Weil in der Realität scheitern ja auch. Was war das im Chaos-Report? Den gibt es, glaube ich, zu Projekten. Ich glaube, zwei Drittel aller Projekte scheitern in irgendeiner Form. Werden nicht rechtzeitig fertig, kosten mehr oder irgendwelche Features fehlen. Und von daher ist es eher die Normalität in der Realität, dass Projekte nicht erfolgreich sind. Jetzt mal, ja klar, in der Prüfung will man natürlich, dass das Projekt erfolgreich ist. Man denkt ja auch an die Note und so. Und ehrlich gesagt, ich habe noch keine Projekte dabei gelesen, wo das Projekt tatsächlich gescheitert ist.

[10:14] Überraschenderweise funktionieren die IHK-Projekte alle. Ja, es ist klar, es geht ja hier um eine Prüfung. Das ist vielleicht nicht so das echte Leben. Und man schreibt natürlich vielleicht auch nicht hundertprozentig alles auf, was nicht gut funktioniert hat. Das ist ja auch alles in Ordnung. Aber grundsätzlich wäre es kein Problem, wenn das Projekt in irgendeiner Form scheitert, weil das sogar eher realistisch ist, als alles schön zu reden und zu schreiben.

[10:35] So, also wir fassen nochmal zusammen. In der Realität musst du mit deinen Fehlern ja auch irgendwo umgehen. Das erwarten wir von einem professionellen Softwareentwickler, Administrator oder was auch immer du als IT-Beruf lernst. Und so erwarte ich das dann auch von dir in der Prüfung. Also wenn du jetzt merkst, Mensch, ich habe da einen Fehler gemacht, dann ist die Frage, was hätte ich denn tun können, um den zu vermeiden? Was mache ich, damit es beim nächsten Mal nicht nochmal passiert? Was habe ich jetzt im Nachhinein getan, um den Fehler zu beheben? Und das wäre dann ein Inhalt, der dann in der Projektpräsentation zum Beispiel kommen könnte, wenn der Fehler so groß ist, dass sich das lohnt oder wichtig ist, das anzusprechen. Bleiben wir nochmal bei meinem Beispiel mit meiner Amortisationsrechnung. Wenn sich das Ding erst drei Monate später amortisiert, aber das Projekt, weiß ich nicht, trotzdem zehn Jahre im Einsatz ist und es keinerlei Ausführung darauf hätte, das Projekt umzusetzen oder nicht, ob die Amortisation jetzt drei Monate später oder früher stattfindet. Also, das war jetzt ein komischer Satz. Also angenommen, egal ob du ein oder zwei Monate später dein Projekt erst amortisierst, wenn es keine Ausführung darauf gehabt hätte, dass du das Projekt auch umsetzt, weil das Projekt sowieso viel länger im Einsatz ist als diese ein, zwei Monate, dann ist das ja im Prinzip irrelevant für die Entscheidung, die du aus dieser Amortisationsrechnung triffst, nämlich das Projekt umzusetzen. Wenn sich jetzt herausstellt, oh, ich habe so viele Kosten vergessen, dass sich das Projekt niemals amortisieren wird, das ist natürlich ein anderes Thema. Das musst du dann natürlich nochmal ansprechen.

[11:54] Aber wenn es jetzt ein, zwei Monate, okay, du hast einen Rechenfehler drin, ja, dann würde ich sogar so weit gehen, in der Präsi einfach die korrigierte Amortisationsrechnung zu zeigen und eventuell mit einem kleinen Nebensatz darauf hinzuweisen. Ach, übrigens in der Projektmodellation habe ich mich hier ein bisschen verrechnet, das waren zwei Monate mehr oder weniger, was auch immer. Das Endergebnis ist aber das gleiche. Wir setzen das Projekt um, weil, lalalala, also eine Begründung wäre natürlich trotzdem interessant. Das heißt, in der Projektpräsentation auf jeden Fall immer die korrigierte Variante zeigen. Es ist absolut bescheuert, wenn du etwas Fehlerhaftes gefunden hast in deiner Doku, das dann fehlerhaft zu übernehmen in die nächste Prüfungsleistung, obwohl du weißt, dass es falsch ist. Das ist einfach dämlich. Das kannst du in der Realität auch nicht machen, wenn du weißt, das Projekt, ich bleibe immer bei diesem Beispiel, weil das so schön griffig ist mit der Amtionsrechnung, das kannst du auch auf alle möglichen anderen Inhalte deines Projekts beziehen. Wenn du weißt, dass das fehlerhaft ist und du zeigst es dann.

[12:47] Das ist doch super unprofessionell. Du musst es doch korrigieren, auch in der Realität. Weil die Leute werden ja vielleicht sogar, im besten Fall, werden sie das nachrechnen, was du da gezeigt hast und merken dann, hä, das ist ja fehlerhaft. Warum ist das denn nicht aufgefallen? Und dann musst du sagen, ach ja, eigentlich ist es mir aufgefallen, aber ich habe es nicht korrigiert. Ich meine, wie dumm ist das? Also du hast einen Fehler gemacht, dann musst du dazu stehen und dann musst du vor allem dafür sorgen, dass das Ding korrigiert wird und dass jetzt halt irgendwie nicht dein Unternehmen Geld verliert, weil du da irgendwo einen Fehler gemacht hast. Also, es ist, wie gesagt, es ist ja menschlich, Fehler zu machen, aber man muss halt damit umgehen und sie ausbügeln, sag ich mal. Also, bei den Prüfenden würde ich jetzt halt sagen, ja, kurz ansprechen, war falsch, ist aber egal quasi, weil Endergebnis ist das Gleiche und fertig. Wenn du jetzt richtig krasse Fehler gemacht hast in deinem Projekt, dann würde ich da vielleicht eine extra Folie für machen und sagen so, hier anders als geplant konnte ich diese drei Features nicht umsetzen, weil, so, und dann wird das halt vernünftig erklärt und dann musst du aber auch mit den Konsequenzen nehmen und sagen, ja, ich konnte die nicht umsetzen, dafür habe ich aber die Zeit in andere Sachen investiert oder es hat sich herausgestellt, es hat länger gedauert, dadurch sind die Features weggefallen, der Kunde war aber trotzdem zufrieden, weil das waren nur die Soll-Features und nicht die Muss-Features oder wie auch immer. Also du musst es halt auch erklären, was jetzt passiert. Und das unterscheidet halt, wie gesagt, einen professionellen ITler oder ITlerin von jemandem, der sagt, oh Fehler, interessiert mich nicht, ich mache nur, was man mir sagt, ich denke nicht nach. Ja, sowas wollen wir nicht.

[14:08] Okay, Hinweis nochmal zu den Prüfenden. Der Prüfungsausschuss muss ja paritätisch mit mindestens drei Menschen besetzt sein. Lehrer, Lehrerin, Arbeitnehmerin und Arbeitgeberin, Vertreter. Und jetzt ist es einfach so, du weißt, die machen das alle im Ehrenamt, kriegen dafür keine Kohle. Und in den meisten Prüfungsausschüssen wird es so sein, dass nicht alle Leute, die da sitzen, deine Dokumentation überhaupt gelesen haben. Also mindestens zwei sollten es schon sein, weil wenn ein Mensch alleine über die Note entscheidet, das ist ja auch nicht ganz richtig. Aber sind wir ehrlich, in der Realität muss das Ganze auch irgendwie in endlicher Zeit stattfinden. Und wenn ich mir vorstelle, ich habe glaube ich, dieses Jahr haben wir 40 Prüflinge, mündliche Prüfungen bei uns. Und wenn ich 40 Projektdokumentationen lesen müsste, wann soll ich das machen? Das ist ja mehr als eine ganze Arbeitswoche, die ich nur für das Lesen benötige. Das ist unmöglich, das darzustellen. Und das heißt, die meisten Prüflinge, nicht Prüfungsausschüsse in der Realität, werden die Arbeit in irgendeiner Form aufteilen. Und dann kann das so sein, dass zwei Leute aus dem Prüfungsausschuss deine Doku gelesen haben, aber die anderen, die da eventuell noch sitzen und mindestens eine Person ist das, die haben deine Doku eventuell gar nicht gesehen, gelesen.

[15:19] Das ist nochmal ein anderes Thema auch für die Präsentation. Geh davon aus, dass nicht alle Prüfenden deine Doku kennen. Das heißt, erzähl alles nochmal, als wenn da jemand sitzen würde, der es noch nie gehört hat. Aber das ist nochmal ein Thema für eine andere Episode. Aber heute geht es ja darum um die Fehler. Das heißt, wenn zwei Leute die Doku gelesen haben und zwei vielleicht diesen Fehler, den du gemacht hast, erkannt haben, die dritte Person, die weiß davon vielleicht noch gar nichts, weil sie deine Doku gar nicht kennt. Ja, manchmal sitzt übrigens noch mehr Leute im Prüfungsausschuss und die haben dann sicherlich auch alle die Doku nicht gelesen oder doch. Es kommt auf die IHK an. Also man kann es auch nicht pauschal sagen, aber meiner Erfahrung nach wird in den meisten Ausschüssen die Arbeit aufgeteilt, sodass nicht alle deine Projektdokumentation überhaupt kennen. Und dann kannst du dir überlegen, wenn du jetzt den Fehler lang und breit erklärst, wo eine Person mindestens dabei ist, die den Fehler noch gar nicht gesehen hat, dann ist das vielleicht ein bisschen verschenkte Zeit.

[16:05] Also fokussier dich nicht auf deine Fehler. Geh kurz darauf ein. Zeig, was du daraus gelernt hast und was du getan hast, um den Fehler zu korrigieren. Aber mach da jetzt nicht einen mega Aufstand von. Weil im Zweifel wissen gar nicht alle, dass du diesen Fehler überhaupt gemacht hast. Und selbst die Prüfenden, die deine Doku gelesen haben, denen ist der Fehler vielleicht auch gar nicht aufgefallen. Ich meine, das ist ja manchmal nicht so offensichtlich, dass da ein richtig krasser Schnitzer drin ist. Deswegen bitte nicht so den Fokus drauflegen. Aber wenn du es erkannt hast, dass es falsch war, dann bitte ansprechen. Und vor allem erzählen, was du daraus gelernt hast, wie du damit umgegangen bist.

[16:37] So, ansonsten, wenn du zum Beispiel einen Fehler gemacht hast bei irgendwas, was du in der Präsi gar nicht zeigen willst, auch nochmal ein Thema für eine andere Episode, die Präsi sind 15 Minuten, da kannst du nicht dein gesamtes Projekt zeigen. Es ist einfach viel zu kurz, das heißt, du hast weniger Möglichkeiten als in einer Doku. Jetzt mal nur ein Beispiel, du hast 10 Diagramme in einer Doku, in der Präsi kannst du aber nur 5 davon zeigen, weil die Zeit nicht reicht. Wenn du einen Fehler gemacht in einem der Diagramme, was du gar nicht zeigst, dann sollte es ein bisschen gesunder Menschenverstand sein, zu sagen, ich habe einen Fehler gemacht, den ich in der Präsi gar nicht zeige, dann brauche ich auch nicht darauf eingehen. Also du musst dich ja nicht selber schlechter machen, als du bist. Du musst ja deine Präsi nicht anfangen mit, ich habe übrigens hier und da und dort noch sieben Fehler gemacht, da gehe ich zwar heute gar nicht darauf ein, weil diese Artefakte interessieren hier in der Präsi niemanden, aber ich erzähle es euch trotzdem, dass ich Fehler gemacht habe. So, das ist natürlich Quatsch. Aber wenn du zum Beispiel, weiß ich nicht, in einem Verteilungsdiagramm einen Fehler in der Doku hattest und zeigst das Verteilungsdiagramm auch in der Präsentation, dann wäre es natürlich sinnvoll, dieses Diagramm zu korrigieren und kurz zu sagen, hey, in der Doku hatte ich das auch, da ist mir aber ein kleiner Fehler unterlaufen, so habe ich das korrigiert. So, das reicht ja schon. Du musst nicht stundenlang dich selber geißeln, sagen, oh Gott, ich habe es falsch gemacht, sondern es ist sehr wichtiger, wie gehst du damit um? Wie gesagt, immer der Blick auf die Zukunft. Was habe ich gemacht, damit es nicht normal vorkommt? Wie habe ich den Fehler korrigiert? Was ist das für eine Konsequenz für das Projekt gewesen? Das ist das, was wir da sehen wollen. Und dann kannst du sogar.

[17:55] Auch mit gemachten Fehlern trotzdem noch mit einem sehr gut aus der Präse oder dem Fachgespräch gehen. Weil das zeigt ja dann eine Professionalität, ich wiederhole mich glaube ich jetzt zum x-ten Mal, wie du mit den Fehlern umgegangen bist. Weil wir können Fehler nicht verhindern, selbst mit dem besten Entwicklungs- und ich weiß nicht was Prozess, können Fehler auftreten. Wir sind halt Menschen, wir sind keine Maschinen und selbst die können Fehler machen, wenn sie falsch programmiert sind. Also viel wichtiger, geh vernünftig mit dem Fehler um, anstatt den irgendwie an den Tisch fallen zu lassen oder noch besser zu leugnen, dass du ihm gedacht hast, nein, das stimmt ja nicht, nein, wo haben sie das denn gelesen? Nicht in meiner Doku. Habe ich auch schon gehabt. Tatsächlich in einer Präsentation, bis wir uns im Fachgespräch danach. Hä? Das weiß ich gar nicht mehr. Steht das so in meiner Doku wirklich? So nach dem Motto, wollen Sie mich gerade verarschen? Und also das geht überhaupt gar nicht. Also wenn du Fehler machst, dann steh dazu und erklär, was du daraus gelernt hast und wie du sie korrigiert hast. Das ist es. Und wenn die Inhalte aber nicht in einer Präsentation vorkommen, wie gesagt, Verteilungsdiagramm zeigst du gar nicht, dann sprich es auch nicht an.

[18:52] Aber bereite dich auf das Fachgespräch vor mit diesem Fehler. Denn natürlich haben mindestens zwei, würde ich mal behaupten, Prüfende deine Doku gelesen und vielleicht diesen Fehler gefunden. Und das vielleicht machen wir mal zu sehr wahrscheinlich haben sie diesen Fehler gefunden, weil das ist ja die Aufgabe der Prüfenden, deine Arbeit zu kontrollieren. Dann werden sie wahrscheinlich solche Fehler finden. Und dann werden sie dich vielleicht auch im Fachgespräch darauf ansprechen. Auch hier wieder, das ist alles vielleicht, vielleicht, vielleicht, weil das Fachgespräch sind ja auch nur 15 Minuten und da wollen wir auch noch viele andere Sachen fragen und nicht nur auf deinen Fehlern rum. Also wenn es jetzt ein krasser Schnitzer ist und ich habe den als Prüfender gefunden, dann spreche ich dich darauf an. Aber eventuell auch nicht, weil ich habe noch tausend andere Themen, die ich mit dir besprechen will in 15 Minuten und dann interessiert mich der Fehler gar nicht. Aber vorbereiten darauf kannst du dich trotzdem, weil wenn man dich dann anspricht, so hier, haben Sie ja nicht gesehen, in Ihrem Verteilungsdiagramm, da fehlt ja noch hier der Server und das passt ja so gar nicht. Dann kannst du sagen, oh ja, das ist richtig, das habe ich auch gesehen. Inzwischen ist es auch korrigiert und das hat folgende Konsequenz, bla bla bla.

[19:49] Und dann ist die Sache fein. Und dann kann man den eventuellen Fehler in der Doku dafür abziehen, dass du diesen, also kann man dir einen Punkt in der Doku dafür abziehen, dass du diesen Fehler gemacht hast. Aber im Fachgespräch kriegst du sogar einen Pluspunkt dafür, weil du dich darum bemüht hast, das zu korrigieren, das erkannt hast. Und das spricht ja auch für irgendeine Form von Qualitätssicherung, dass es im Nachhinein zumindest nochmal aufgefallen ist, dass der Fehler da war und dass du ihn auch korrigiert hast und so weiter.

[20:13] Also, ja, jetzt sind wir doch bei 20 Minuten gelandet. Ich wollte auf jeden Fall sagen, wenn du Fehler gemacht hast, steh dazu, Du sprichst sie gegebenenfalls sogar an, geh aktiv damit um, zeig, dass du professionell mit solchen Fehlern umgehen kannst, dass du was daraus gelernt hast, dass du irgendetwas tust, damit das in Zukunft nicht nochmal passiert. Das wäre vielleicht das Wichtigste, Learning, dass du das einmal zeigst. Aber du musst dich nicht auf deine Fehler fokussieren. Du musst nicht sagen, oh, das und das und das war alles falsch. Vor allem nicht beinhalten, die du eh nicht in der Präsentation hast. Aber bereite dich auf mögliche Fragen im Fachgespräch dazu vor. Das wäre auf jeden Fall sinnvoll. Also, ich hoffe, das hat dir jetzt ein bisschen geholfen. Wenn dir Fehler auffallen, dreh nicht durch. Auch im Nachhinein. Ich habe es schon eingangs gesagt, Dokus gehabt, wo direkt auf der Titelseite der Dokumentation Rechtschreibfehler war. Ja nun, das kann halt passieren. Das erkennt man meistens erst, nachdem man auf Absenden gedrückt hat und die Doku unwiderruflich hochgeladen wurde. Das ist manchmal so. Also mach dich nicht verrückt wegen solcher kleinen Fehler oder auch selbst wegen größerer Fehler, wenn du irgendwo zwei Stunden eine Zeitplanung vergessen hast. Deswegen fällst du nicht durch die Prüfung, deswegen kriegst du keine vier, sondern es ist immer ein großes Gesamtkunstwerk, dieses Projekt. Und da kann links und rechts mal ein kleines Fehlerchen auftreten, das ist überhaupt kein Problem. Trotzdem kannst du noch eine gute oder sehr gute Note bekommen. Für solche Sachen dreht dir da keiner den Hals um.

[21:33] Man dreht dir aber den Hals um, wenn du die Sachen ignorierst, wenn du sie bewusst leugnest, dass es den Fehler gibt oder so etwas. Das ist absolut unprofessionelles Verhalten. Überleg mal, das würdest du im Alltag auch nicht machen, wenn dein Chef zu dir kommt und sagt, sie haben hier aber was falsch gemacht. Nein, Chef, auf gar keinen Fall. Und es war jemand anders.

[21:51] Also wie lange willst du dann da noch arbeiten? Kannst du dir überlegen. Wenn du Fehler machst, steh dazu, überleg dir, wie du damit umgehst, wie du es in Zukunft verhinderst. Vielleicht kennst du den Spruch, ich weiß nicht, ist angeblich so ein Urban Myth, Ich glaube von so einem IBM-Manager, der irgendwie mal so einen Mitarbeitenden zu sich gerufen hat und gesagt hat, hier, was haben Sie denn da für einen Fehler gemacht? Das hat 100.000 Euro gekostet oder Dollar oder was auch immer. Und dann hat der Mitarbeiter schon befürchtet, oh Gott, der schmeißt mich raus und Hilfe. Und der Chef schmeißt ihn aber nicht raus. Und dann fragt er, wieso wäre ich denn jetzt nicht rausgeschmissen? Ja, weil ich gerade 100.000 Dollar in ihre Fortbildung investiert habe. So ganz blöd gesagt. Also wenn du aus den Fehlern lernst, dann ist das doch fürs Unternehmen am Ende gut, weil ganz sicher, vorausgesetzt du lernst wirklich daraus, wirst du diesen Fehler ja nicht nochmal machen. Jemand anders, der den Fehler aber nicht gemacht hat, der kann ihn vielleicht wiederholen und deswegen ist das tatsächlich auch eine Investition in dich als Mitarbeitenden, wenn man dir die Fehler verwendet.

[22:48] Wie soll ich das sagen? Durchgehen lässt sich blöd an. Natürlich wollen wir keine Fehler machen. Niemand ist daran interessiert, dass alle Mitarbeiter möglichst viele Fehler machen. Das ist ja Quatsch. Aber wenn mal ein Fehler passiert, dann sollte man daraus lernen und dann sollte das Unternehmen daraus lernen, wie man sowas in Zukunft verhindern kann. Das ist professionelles Vorgehen und Fehler zu leugnen und zu sagen, ich war es gar nicht oder das ist aber nicht meine Schuld, das bringt niemanden weiter und stellt dich auch in ein ganz schlechtes Licht und ja, das wollen wir auch, wir wollen ja die Prüfung möglichst realitätsnah haben und in der Realität wollen wir solche Mitarbeitenden auch nicht haben, also fang nicht an, irgendwas zu leugnen oder zu widersprechen oder ja, das kommt gar nicht gut an, weder in der Realität noch in der Prüfung. Steh dazu, lehren daraus, mach es beim nächsten Mal besser. Das ist die Kernaussage. So, ich glaube, jetzt habe ich alles. Ich hoffe, du hast meine Einstellung dazu verstanden. Und ja, wenn du anderer Meinung bist, schreib mir gerne einen Kommentar oder vielleicht hast du sogar Beispiele, wo du selber einen Fehler zugegeben hast und wo es positiv ausgegangen ist. Ganz besonders freuen würde ich mich natürlich auch über Gegenbeispiele. So, hey, ich habe einen Fehler zugegeben. Am Ende haben sie gesagt, du bist durchgefallen, wenn du einen Fehler gemacht hast. Das fände ich absolut realitätsfähig in der Prüfung. Aber bei 79 IHK mit jeweils x verschiedenen Prüfungsausschüssen kann das deutschlandweit natürlich auch noch ein bisschen anders gehandhabt werden. Also das hier ist jetzt meine Meinung für einen professionellen Umgang mit Fehlern. Wenn du andere Erfahrungen gemacht hast oder Geschichten gehört hast, kommentiere gerne unter der Episode, das würde mich sehr interessieren natürlich.

[24:10] Ansonsten hoffe ich, dass es heute ein bisschen geholfen hat. Ich wünsche dir viel Erfolg für deine Projektpräsentation und das Fachgespräch und falls du noch nicht abgegeben hast, auch die Doku. Und da nochmal, der beste Fehler ist der, den du gar nicht machst. Das heißt, wenn du vor Abgabe der Doku nochmal jedem mal über die Doku drüber gucken lässt, zum Beispiel Ausbilder, Ausbilderin oder im Jahr 2026 vielleicht auch die KI, die dann sowas wie Kommasetzungsfehler oder Rechtschreibung zumindest glatt ziehen würde, das wäre auf jeden Fall auch empfehlenswert.

[24:36] Denn wenn du einen Fehler gar nicht zugeben musst, weil du ihn nicht gemacht hast, ist das natürlich das Optimum. So, jetzt haben wir es aber auch. Vielen Dank fürs Zuhören und bis zum nächsten Mal.

Um eine sinnvolle Prüfungsvorbereitung mit alten IHK-Prüfungen geht es in der elften Episode der Shorts des IT-Berufe-Podcasts.

Ich empfehle dir, für die schriftliche Abschlussprüfung mit alten Prüfungen zu lernen und dabei mit den neuesten anzufangen. Wichtig ist aber, dass du immer den aktuell gültigen Prüfungskatalog prüfst, weil sich Inhalte durch Neuordnungen und Anpassungen verschieben oder wegfallen können. Für WiSo sind auch sehr alte Prüfungen sinnvoll, bei AP1 und AP2 musst du genauer schauen, welche alten Prüfungen thematisch noch zu deinem Prüfungsteil passen und dir idealerweise zusätzlich Feedback von deinem/deiner Ausbilder:in holen.

Inhalt

Alte Prüfungen sind grundsätzlich sinnvoll

Ich halte es für sehr sinnvoll, dich mit alten Prüfungen auf die schriftliche Abschlussprüfung vorzubereiten. Das gilt sowohl für AP1 als auch für AP2. Am besten startest du aber immer mit den neuesten Prüfungen und arbeitest dich dann chronologisch rückwärts vor. Je aktueller eine Prüfung ist, desto höher ist die Wahrscheinlichkeit, dass sie noch gut zu den heutigen Anforderungen passt.

Wichtig ist dabei eine Einschränkung: Du solltest alte Prüfungen nie blind durcharbeiten, sondern immer mit dem aktuell gültigen Prüfungskatalog abgleichen. Inhalte können sich durch die Neuordnung der IT-Berufe oder durch Änderungen am Prüfungskatalog verschieben, neu dazukommen oder wegfallen.

Was sich seit der Neuordnung verändert hat

Vor der Neuordnung 2020 gab es:

eine Zwischenprüfung

eine Abschlussprüfung mit:

GA1

GA2

WiSo

Alte Zwischenprüfung

Die frühere Zwischenprüfung ist mit den heutigen Prüfungen praktisch nicht mehr vergleichbar. Sie bestand stark aus Multiple Choice und behandelte allgemeine IT-Themen für alle IT-Berufe. Dieser Prüfungsteil wurde ersatzlos gestrichen. Deshalb ist er für deine Vorbereitung heute nicht mehr relevant.

WiSo

Beim WiSo-Teil hat sich im Grunde nichts Wesentliches verändert. Die Themen und die Art der Fragen sind seit vielen Jahren ähnlich geblieben. Es geht dort um allgemeine wirtschaftliche und soziale Inhalte wie:

Wirtschaft, Rentabilität

Märkte, Angebot und Nachfrage

Arbeitsverträge

Gewerkschaften, Streik, Betriebsrat

Deshalb kannst du für WiSo auch sehr alte Prüfungen verwenden, sogar viele Jahre zurück. Als Untergrenze empfehle ich mindestens die letzten fünf Jahre, also bei zwei Terminen pro Jahr etwa zehn Prüfungen.

Wie alte und neue Prüfungsteile zusammenhängen

Für die fachlichen Teile gibt es grobe Entsprechungen zwischen alt und neu:

alte GA1 entspricht am ehesten der heutigen AP2

alte GA2 entspricht am ehesten der heutigen AP1

Der Hintergrund:

Die GA1 war berufsspezifisch, ähnlich wie die heutige AP2.

Die GA2 war für alle IT-Berufe gleich und damit eher mit der heutigen AP1 vergleichbar.

Warum du immer den aktuellen Prüfungskatalog brauchst

Es gab nicht nur 2020 eine große Neuordnung, sondern auch weitere Änderungen:

2018: kleinere Reform mit Datenschutz und Datensicherheit in der Prüfung

2020: große Überarbeitung der IT-Berufe

2025: Anpassung der Prüfungskataloge

Dadurch kann es passieren, dass alte Prüfungen Themen enthalten, die heute nicht mehr geprüft werden, oder umgekehrt, dass heute Themen relevant sind, die in älteren Prüfungen noch gar nicht vorkamen.

Ein Beispiel dafür ist SQL:

In der AP1 wurde SQL mit dem neuen Prüfungskatalog gestrichen.

In der AP2 ist SQL heute relevant.

Deshalb kann es sein, dass du für bestimmte Berufe oder Prüfungsteile passende SQL-Aufgaben nicht direkt in alten AP2-Prüfungen findest, sondern eher in älteren AP1-Prüfungen oder in AP2-Prüfungen anderer IT-Berufe, zum Beispiel der Anwendungsentwicklung.

Ein weiteres Beispiel ist RAID, das in der AP1 ebenfalls nicht mehr relevant ist, aber in älteren Prüfungen noch häufig vorkommt.

So gehst du bei alten Prüfungen sinnvoll vor

Ich empfehle dir dieses Vorgehen:

Prüfungskatalog besorgen

Dort steht, welche Themen aktuell für AP1 oder AP2 in deinem Beruf relevant sind.

Mit den neuesten Prüfungen anfangen

Zuerst den Prüfungsteil bearbeiten, auf den du dich konkret vorbereitest.

Dann chronologisch rückwärts arbeiten

So lange, bis du bei den Prüfungen ab 2020 angekommen bist.

Danach Prüfungstrainer nutzen

Zum Beispiel die Prüfungstrainer aus dem U-Form-Verlag mit prüfungsnahen Aufgaben und Lösungen.

Erst danach sehr alte Prüfungen ergänzend anschauen

Für AP2 eher alte GA1

Für AP1 eher alte GA2

Wichtig ist dabei immer: Wenn ein Thema heute neu in einem Prüfungsteil ist, kannst du auch in anderen alten Prüfungen nach passenden Aufgaben suchen, selbst wenn sie ursprünglich für einen anderen Prüfungsteil oder einen anderen IT-Beruf gedacht waren.

Lass dich von alten Aufgaben nicht verunsichern

Wenn du in älteren oder auch noch relativ neuen Prüfungen Aufgaben zu Themen findest, die laut aktuellem Prüfungskatalog nicht mehr drankommen sollen, ist das kein Widerspruch. Der Grund ist einfach, dass diese Prüfungen noch auf älteren Regelungen basieren.

Deshalb gilt:

Nicht jede alte Aufgabe ist heute noch relevant.

Nicht jedes heute relevante Thema ist in alten Prüfungen sofort leicht zu finden.

Maßgeblich ist immer der aktuelle Prüfungskatalog.

Wenn dort ein Thema nicht mehr enthalten ist, musst du es bei knapper Zeit nicht gezielt für diesen Prüfungsteil lernen. Es ist natürlich trotzdem nicht falsch, solche Inhalte grundsätzlich zu können.

Lösungen nie nur stumpf vergleichen

Wenn du mit alten Prüfungen lernst, solltest du deine Antworten nicht nur mit den Lösungshinweisen vergleichen. Dabei gilt:

Es gibt meist keine echten Musterlösungen, sondern nur Lösungsvorschläge oder Lösungshinweise.

Gerade bei offenen Aufgaben kann es mehrere richtige Wege geben.

Das betrifft zum Beispiel:

Datenbankmodellierung

Pseudocode

andere Aufgaben mit Transferleistung

Deshalb musst du nicht verzweifeln, wenn deine Lösung anders aussieht als auf dem Lösungbogen. AP1 und AP2 werden von Menschen korrigiert, die dabei einen Bewertungsspielraum haben.

Feedback ist ein wichtiger Teil der Vorbereitung

Ich finde es sinnvoll, alte Prüfungen gemeinsam mit deinem/deiner Ausbilder:in oder einer anderen fachkundigen Person durchzusprechen. So kannst du besser einschätzen:

ob deine Lösung trotzdem Punkte bekommen würde

wo deine Denkfehler liegen

ob eine alternative Lösung fachlich in Ordnung ist

Besonders hilfreich ist das bei offenen Aufgaben, bei denen nicht nur eine einzige Formulierung korrekt sein kann. Im Ausbildungsalltag mit meinen eigenen Azubis wird etwa jeden Monat eine alte Prüfung bearbeitet und danach mit einem/einer Ausbildungsbeauftragten besprochen.

Fazit

Ja, du kannst auch mit ganz alten Prüfungen lernen. Ich würde aber nicht damit anfangen. Mein Vorschlag ist:

zuerst die neuesten Prüfungen

dann passende Prüfungstrainer

danach bei Bedarf ältere Prüfungen

und sehr alte Prüfungen nur ergänzend und gezielt

Für WiSo sind auch sehr alte Prüfungen gut nutzbar. Für AP1 und AP2 musst du dagegen genauer prüfen, welche Aufgaben heute noch zu deinem Prüfungskatalog passen. Alte Prüfungen sind ein wichtiger Bestandteil der Vorbereitung, am sinnvollsten zusammen mit Feedback und ergänzt durch eigenes Lesen, Umsetzen, Programmieren oder Administrieren.

Links

Permalink zu dieser Podcast-Episode

RSS-Feed des Podcasts

Vorbereitung auf die schriftliche Abschlussprüfung

Fachinformatiker Anwendungsentwicklung: Prüfungstrainer Abschlussprüfung Teil 2

Fachinformatiker Systemintegration: Prüfungstrainer Abschlussprüfung Teil 2

Transkription der gesamten Episode

Automatisch erzeugte Transkription der Episode

[0:20] Heute geht es um ein Thema, was regelmäßig inzwischen viermal im Jahr immer wieder angefragt wird. Und zwar, wie bereite ich mich am besten auf die schriftliche Abschlussprüfung vor? Warum viermal im Jahr? Naja, es gibt vier Termine im Jahr. Es gibt zweimal die AP1 im Frühjahr und im Herbst und zweimal die AP2 im Sommer und im Winter. Und immer sind die Fragen dieselben. Wie bereite ich mich darauf vor? Was kommt dran? Etc. Ich habe, glaube ich, als allererste Folge oder eine meiner allerersten Folgen in diesem Podcast schon Tipps zur Prüfungsverwaltung gegeben und habe ich vor kurzem auch nochmal aktualisiert. Aber heute geht es um eine ganz spezielle Frage in diesem Zusammenhang. Und zwar kann, soll, muss ich auch mit älteren Prüfungen mich vorbereiten? Oder soll ich nur die neuesten Prüfungen durchgehen? Und ja, da möchte ich auch mal drauf eingehen. Kurz vorweg schon mal, guck dir am besten so viele alte Prüfungen wie möglich an. Das kann auf jeden Fall nicht schaden. Aber mit einer kleinen Einschränkung bedenke immer, was der aktuelle Umfang an Themen für deine konkrete Prüfung ist, die gerade vor dir steht, weil der kann sich ändern.

[1:23] So, und jetzt tun wir mal ein bisschen weiter aus. Vor der Neuordnung der IT-Berufe 2020 gab es eine Zwischenprüfung und eine schriftliche Abschlussprüfung. Die Zwischenprüfung, das sage ich schon mal gleich vorweg, die kannst du eigentlich mit keiner der heutigen Prüfungen mehr vergleichen. Das war ganz viel Multiple Choice und einmal rundum um alle möglichen IT-Sachen für alle Berufe, auch gleich für alle IT-Berufe. Und der Prüfungsteil ist tatsächlich einfach ersatzlos gestrichen und den brauchst du dir tatsächlich auch nicht mehr angucken. Das kannst du ad acta legen, das interessiert keinen Menschen mehr.

[1:53] Aber dann gab es noch die eigentliche Abschlussprüfung früher, war ja nicht aufgeteilt in 1 und 2, sondern eben die Zwischenprüfung und dann kam die Abschlussprüfung und da gab es zwei Teile. Einmal die sogenannten ganzheitlichen Aufgaben 1 und ganzheitliche Aufgaben 2, GA1 und GA2 oder GH1, GH2 abgekürzt. Und den Visoteil. Und den Visoteil, den Spoiler ich schon mal, der ist, da kannst du dir eigentlich alle Prüfungen auch von vor 20 Jahren angucken, weil die Themen sind halt im Großen und Ganzen gleich geblieben. Die Fragestellung ist gleich geblieben. Es ist Multiple Choice, genau wie früher. Es wird mal schnell ausgewertet. Also an der Prüfung hat sich eigentlich überhaupt gar nichts verändert. Und die ist ja noch nicht mal nur für die IT-Berufe gleich, sondern so ziemlich für alle anderen Berufe auch gleich. Es sind halt ganz allgemeine Fragestellungen zur Wirtschaft, zu Märkten, zu, weiß ich nicht, Arbeitsverträgen und einfach Wirtschaft und Soziales. Es hat halt eigentlich nichts mit IT zu tun. Das heißt, wenn du die Prüfung dir angucken willst, auch die letzten 20 Jahre rückwärts, mach das, super Idee. Ansonsten sage ich ja, mindestens die letzten 5 Jahre angucken und da hast du, weil es ja aktuell 2 Prüfungstermine pro Jahr gibt, schon mal 10 Prüfungen, auf jeden Fall locker und hast damit einen Großteil der Fragen, die dir gestellt werden, in deiner Visu-Prüfung wahrscheinlich abgedeckt. Also das ist das Ding, wo du am einfachsten für lernen kannst mit alten Prüfungen, würde ich sagen. So, und dann gab es aber noch die GA1 und GA2.

[3:13] Und damals war es halt auch schon so, dass wir einen Teil in der Prüfung hatten, der für alle IT-Berufe gleich war. Das war in diesem Fall die GA2. Und dann gab es den Teil, der für den jeweiligen Beruf fachspezifisch war, also Anbietungsentwicklung, Systemintegration, etc. Und das war die GA1. Und jetzt kann man am ehesten vergleichen die alte GA1 mit dem, was wir heute in der AP2 schreiben. Weil das ist ja rein fachspezifisch. Die AP2 ist komplett unterschiedlich für jeden IT-Beruf. Das ist das, was früher die GA1 war. Und die alte GA2 ist am ehesten vergleichbar mit dem, was wir heute in der AP1 schreiben. Also Inhalte für alle IT-Berufe gleich, eher oberflächlich, eher in die Breite.

[3:54] So, und jetzt kannst du dir natürlich vorstellen, wenn es diese alten Prüfungen gibt, vielleicht kann man die ja noch zum Lernen benutzen. Und ich würde sagen, ja klar, kannst du die dafür benutzen. Trotzdem würde ich natürlich empfehlen, mit den neuesten Prüfungen anzufangen. Ist ja klar, du machst eine neue Ausbildung im Jahr, weiß nicht, 2026, 2027, schreibst du die Prüfung. Da ist es vielleicht nicht sinnvoll, sich Prüfungen von 1997 anzugucken. Da hat sich inzwischen natürlich auch sehr viel geändert. Aber es ist ja nun mal so, in der IT gibt es mal eine Neuordnung. Die letzte war 2020. Davor tatsächlich, hat kaum jemand mitbekommen, aber 2018 gab es auch eine kleine Reform der IT-Berufe. Da wurde nämlich zum Beispiel Datenschutz und Datensicherheit mit in die Prüfung aufgenommen, was vorher gar nicht explizit drin war. So, das heißt, wir hatten 2018 eine kleine Anpassung, 2020 die große Überarbeitung der IT-Berufe. Und jetzt gibt es aber auch noch sowas wie die Anpassung der Prüfungskataloge. Und das hat jetzt 2025 zuletzt stattgefunden. Das heißt, da wurde nicht der Beruf überarbeitet, sondern nur die Liste der Themen, die in der Prüfung drankommen können. Sowas kann ja auch passieren. So, und jetzt haben wir halt folgende Situation. Egal, welche alte Prüfung du dir anguckst, es kann sein, dass sie nicht mehr zu dem passt, was du in deiner Prüfung abgefragt werden kannst, weil sich entweder der Beruf oder der Prüfungskatalog oder was auch immer sonst noch geändert hat. Das heißt, grundsätzlich musst du bei alten Prüfungen eh immer gucken, ist das für mich noch relevant und ist das für diese Prüfung, auf die ich mich gerade vorbereite, relevant. Du kannst dir auch alte AP1en angucken. Hilft dir nicht so viel, wenn du dich gerade auf die AP2 vorbereitest.

[5:20] Außer du nimmst eine AP1, in der noch SQL drin war, weil das wurde jetzt gestrichen mit dem neuen Prüfungskatalog 2055, ist aber heute auf jeden Fall in der AP2 überall drin. Das heißt, wenn du dir jetzt alte AP2en zum Beispiel anguckst als FISI, Hast du da vielleicht gar keinen SQL drin? Inzwischen ist das aber notwendig. Es gibt nur leider keine alte Prüfung, wo es drin ist, weil das ist ja erst seit einem Jahr so. Verstehst du das Problem? Ich hoffe, ja. Das heißt, du kannst dir anhand der alten Prüfung auf jeden Fall zu den jeweiligen Themen, die drankommen können, Beispielaufgaben angucken. Und das ist auch absolut sinnvoll, die durchzugehen. Und wenn du jetzt halt merkst, oh, als Fisi muss ich eigentlich SQL können, ja, dann suche ich mir doch alte Prüfungen raus, wo SQL-Aufgaben drin sind. Und das kann dann eine alte AP1 sein, das kann eine AP2 für Anwendungsentwickler sein, weil da war schon immer SQL drin. Also, es kommt halt ganz drauf an, auf welche Prüfung bereitest du dich vor und dann musst du dazu die passenden Prüfungen da anschauen.

[6:11] Ein Riesenthema für alle IT-Berufe gleich ist ja die AP1. Da hat sich jetzt durch einen neuen Prüfungskatalog einiges geändert. Da ist zum Beispiel SQL halt rausgeflogen und RAID zum Beispiel sind so zwei Sachen, die mir auswendig immer einfallen. Wenn du dich jetzt auf die AP1 aktuell vorbereitest, kannst du die beiden Themen streichen, wirst aber in den alten Prüfungen sehr viele Aufgaben dazu finden, weil das früher halt drin war. Und da kommt natürlich auch eine gewisse Unsicherheit. So, hä, im Prüfungskatalog steht es nicht drin, in den alten Prüfungen ist es aber. Ja, weil die halt auf einem alten Prüfungskatalog basierten. Und jetzt kann man natürlich im Internet sich tausend Gerüchte und Diskussionen anschauen. Kann SQL vielleicht doch wieder in der API 1 drankommen? Ja, potenziell ja. Ich habe keine Glaskugel, ich kann es nicht sagen. Aber wenn im offiziellen Prüfungskanalog steht, SQL ist raus.

[6:52] Dann musst du dich erstmal nicht darauf vorbereiten unter der Voraussetzung, dass du nicht genug Zeit hast, um das alles zu lernen. Ist es schlimm, wenn du SQL kannst? Nee, im Gegenteil. Ich finde es super, wenn jeder IT-Lehrerin SQL kann. Und dann ist mir auch egal, ob es zur AP1 oder AP2. Aber wenn du wenig Zeit hast und dich gezielt vorbereiten willst, dann brauchst du dich auf jeden Fall für die AP1 nicht mehr auf SQL vorbereiten. So, und das ist jetzt nur ein Thema. Das kann sich ja nächstes Jahr auch wieder verschieben. Vielleicht gibt es da noch einen neuen Prüfungstilolog. Und es gibt halt auch noch andere Themen außer SQL, die verschoben wurden.

[7:20] Und das will ich eigentlich damit sagen. Du musst einfach schauen, was ist für dich, für deine Prüfung relevant. Und dazu guckst du in den aktuell gültigen Prüfungskatalog. Den kannst du dir für 7,10 Euro, kostet der, glaube ich, beim U-Vorm Verlag kaufen oder von deinem Ausbildungsunternehmen kaufen lassen. Die haben den auch hoffentlich schon, wenn sie ein vernünftiger Ausbildungsbetrieb sind. Und da guckst du rein. Und da steht dann für AP1 musst du lernen, zack, zack, zack, zack. Und für deine AP2 in deinem Beruf musst du lernen, zack, zack, zack, zack. Das ist das, worauf du dich vorbereiten musst. Und dann gehst du alte Prüfungen durch, chronologisch rückwärts, fängst mit den neuesten an, weil da die Chance am größten ist, dass sie schon zu diesem Prüfungskatalog passen. Aber irgendwann wirst du feststellen, spätestens im Jahr 2024 sind Aufgaben drin, die es heute entweder nicht mehr gibt oder die es auf jeden Fall noch mehr geben wird, weil sich halt Themen vielleicht hin und her geschoben haben zwischen den Prüfungsteilen. Und wenn du jetzt alte Aufgaben brauchst für ein Thema, was jetzt neu in der AP2 zum Beispiel gekommen ist, kannst du in alte AP1 gucken oder sogar noch weiter zurück in alte GA2, wenn du für die AP1 lernst zum Beispiel. Also grundsätzlich finde ich es gut, mit allen alten Prüfungen zu lernen, aber es macht natürlich Sinn, mit den neuesten anzufangen. Das ist ja ganz klar.

[8:26] Also lass dich nicht verunsichern, wenn du dann in diesen neueren Prüfungen Aufgaben siehst zu Themen, die eigentlich gar nicht mehr drankommen sollen. Du weißt ja jetzt, woran es liegt. Die Prüfungen. Berufe, aber alle Berufe, nicht nur die Berufe, sind nicht starr. Da wird mal was überarbeitet, da wird mal was hin und her geschoben, was ja auch sinnvoll ist, finde ich. Nur bei den alten Prüfungen wird man dann halt als Prüfling, wenn man sich nicht damit auseinandersetzt, vielleicht ein bisschen verwirrt.

[8:48] Also meine Strategie, fang mit der letzten Prüfung für den Teil, für den du dich vorbereitest, AP1, AP2 an, und gehe dann rückwärts immer weiter zurück, bis du keine Prüfung mehr hast. Und das wird dann im Jahr 2020 sein. dann kannst du gerne zu den alten GA1 oder GA2 wechseln. Irgendwann wird es natürlich dann thematisch nicht mehr ganz so relevant, weil es dann immer mal zehn Jahre her ist. Dafür gibt es dann aber noch als Ergänzung die Prüfungstrainer aus dem U-Form Verlag. Vielleicht kennst du die. Das sind so DIN A4 Büchlein, wo halt auch nochmal, ich glaube, zehn IHK-Prüfungen drin sind. Also prüfungsnahe Aufgaben. Sind keine offiziellen Prüfungen, aber Aufgabenstellungen, die sehr, sehr ähnlich sind. Und natürlich gibt es dazu die entsprechenden Lösungen auch. Und die guckst du dir dann auch noch an. Und dann hast du, also ich nehme es jetzt 2026 hier auf, die Neuordnung war 2020. Das sind dann schon mindestens 10, 11 neue Prüfungen, zumindest nach der Neuordnung, die du machen kannst. Mindestens ein, zwei auch schon nach dem neuen Prüfungskatalog, die du machen kannst. Und wenn dir das dann immer noch nicht reicht, dann guckst du dir halt die alten Prüfungen an. Aber sogar vorher noch würde ich mir die Prüfungstrainer anschauen, weil die sind natürlich auch auf dem neuesten Stand. Also chronologisch rückwärts die letzten Prüfungen, dann die Prüfungstrainer. Und wenn du dann immer noch Zeit über hast, dann guckst du die in Anführungszeichen Uraltprüfungen von früher an und dann wäre die GA1 für die AP2 relevant und die GA2 für die AP1. Also die Zahlen genau umgedreht, wie es früher mal war.

[10:12] So, und wenn du jetzt mit den Prüfungen lernst, wäre es natürlich auch sinnvoll, dass du da auch irgendwie dir ein Feedback zu einholst. Du kannst natürlich in die Musterlösungen gucken, wobei Musterlösungen gibt es da ja nicht. Das sind immer nur Lösungsvorschläge oder Lösungshinweise.

[10:25] Deswegen verzweifle da nicht, wenn du es nicht exakt so formulierst oder exakt so zeichnest, wie es in der Lösung steht. Das sind immer nur Hinweise. Und zumindest die AP1 und AP2 wird von Menschen korrigiert, die da auch einen gewissen Entscheidungsrahmen haben, ob sie da Punkte vergeben oder nicht. Und deswegen würde ich dir den Tipp geben, das immer mit deiner Ausbilderin, mit deinem Ausbilder auch durchzusprechen, was du da an Lösungen hast. Wenn du natürlich die perfekte Muskellösung hingeschrieben hast, super.

[10:52] Aber wenn du Abweichung hast, und das passiert ganz schnell mal, wenn du was modellieren musst, eine Datenbank zum Beispiel, oder wenn du Pseudocode-Aufgaben hast oder so, wo man auch ein bisschen Transferleistung hat, da kriegt man vielleicht nicht die hundertprozentige Musterlösung hin oder hat einfach eine andere Idee, das Problem zu lösen. Stichwort Pseudocode. Gibt es gefühlt 700 verschiedene Wege, irgendwas zu programmieren. Und da ist vielleicht das Feedback von einem anderen Menschen, im besten Fall von jemandem, der sich auskennt, also Ausbilder, Ausbilderin vielleicht, ganz hilfreich, damit du nicht nur in deinem stillen Kämmerlein da irgendwie was lernst und dich ärgerst, wenn du nicht so dicht an der Musterlösung bist. Also, nur mal ein Beispiel, wie ich das oder wie wir das bei uns im Unternehmen mit unseren Azubis machen. Die sollen im Durchschnitt jeden Monat eine alte Prüfung durchgehen und sie dann aber auch nicht nur mit den Musterlösungen stumpf vergleichen, sondern es gibt dann immer auch einen Termin mit einem Ausbildungsbeauftragten bei uns, der das dann mit denen auch durchspricht. Und dann zum Beispiel bei so einer Frage, wie hätte ich hierfür noch einen Punkt gekriegt, auch eine Antwort geben kann. Das wäre natürlich super. Besonders toll wäre es natürlich, wenn diese Person auch Prüfender oder Prüfende ist. Dann kann ich es natürlich nochmal besser sagen, als jemand, der noch nie mit der Prüfung da zu tun hatte. Aber normalerweise sollte man es ja vielleicht ein bisschen einschätzen können, ob die Antwort da passen würde oder nicht.

[12:04] So, und dann wäre das auch mein Tipp, um sich mit alten Prüfungen vorzubereiten. Also Antwort auf die Frage, kannst du mit ganz alten Prüfungen lernen? Ja, wäre nicht mein präferierter Weg. Ich würde das miteinander anfangen, klar, aber je mehr du dich vorbereitest, desto besser, vorausgesetzt du hast genug Zeit dafür und dann kannst du auch mit den älteren Prüfungen lernen, wie gerade schon beschrieben. So, das war meine, ja, nicht ganz so kurze Antwort zur Frage, soll ich auch mit alten Prüfungen lernen, aber ich habe es ein bisschen erklärt, damit du auch weißt, was da der Hintergrund ist. Ich hoffe, es hilft dir ein bisschen bei deiner Prüfungsvorbereitung. Ich drücke dir auf jeden Fall die Daumen, egal, ob du noch die AP1 oder AP2 vor dir hast. Das wird schon. Guck dir die alten Prüfungen an, ergänze das Ganze um Feedback mit deinem Ausbilder, deine Ausbilderin. Natürlich darfst du auch gerne mal ein Buch lesen und auch selber was umsetzen und programmieren und administrieren.

[12:50] Genau, aber die Prüfungen sind sicherlich ein ganz wichtiger Bestandteil, also die alten, um sich auf die neuen Prüfungen vorzubereiten. Jo, das war’s dazu. Ich drück die Daumen für deine Prüfung. Mach’s gut, bis zum nächsten Mal.

Um die sinnvolle Platzierung von Artefakten in der Projektdokumentation geht es in der zehnten Episode der Shorts des IT-Berufe-Podcasts.

Inhalt

Ich empfehle dir für die Projektdokumentation als klare Daumenregel, Artefakte wie Diagramme, Tabellen, Code, Screenshots oder Berechnungen in den Anhang zu packen – besonders dann, wenn sie größer als eine halbe Seite sind. Im Fließtext sollte stattdessen stehen, warum du ein Artefakt erstellt hast, wie es dir im Projekt geholfen hat und was du daraus abgeleitet hast. Nur kleine, direkt erklärungsbedürftige Artefakte können aus Gründen der Lesbarkeit ausnahmsweise in den Fließtext.

Was ich mit Artefakten meine

Mit Artefakten sind alle Bestandteile der Projektdokumentation gemeint, die kein eigentlicher Fließtext sind. Dazu zählen zum Beispiel:

Diagramme wie UML-Diagramme oder ER-Modelle

Tabellen, etwa für Kosten oder Zeitplanung

Code

Netzwerkpläne

Testprotokolle

Berechnungen und Formeln

Screenshots und Fotos

Zentrale Daumenregel

Meine Empfehlung ist klar:

Alle Artefakte gehören grundsätzlich in den Anhang.

Alles, was größer als eine halbe Seite ist, sollte auf jeden Fall in den Anhang.

Nur wenige Ausnahmen sprechen dafür, ein Artefakt direkt im Fließtext zu platzieren.

Warum Artefakte besser in den Anhang gehören

Der wichtigste Grund ist die begrenzte Seitenzahl für den Fließtext. Viele IHKs machen dafür klare Vorgaben, zum Beispiel 15 Seiten Fließtext und 25 Seiten Anhang. Diese Vorgaben unterscheiden sich aber je nach IHK teilweise deutlich.

Wichtig ist deshalb:

Prüfe immer die konkreten Vorgaben deiner IHK.

Verlasse dich nicht pauschal auf Angaben aus dem Internet.

Wenn du Artefakte in den Fließtext einbaust, verbrauchen sie dort Platz. Dadurch bleibt weniger Raum für erklärenden Inhalt, der in der Bewertung oft entscheidend ist. Eine Seite Klassendiagramm im Fließtext ist dann eben keine Seite Fließtext mehr.

Seitenzahl ist nicht das eigentliche Problem

Entscheidend ist nicht, ob am Ende 14 oder 15 Seiten dort stehen. Entscheidend ist, ob wichtige Inhalte fehlen.

Wenn zum Beispiel in einem Projekt ein bestimmtes Artefakt sinnvoll oder zu erwarten ist, dann fehlt ohne dieses Artefakt möglicherweise ein relevanter Inhalt. Umgekehrt hilft es auch nicht, die maximale Seitenzahl auszuschöpfen, wenn dabei inhaltlich etwas Wichtiges fehlt.

Die Seitenzahl ist also nur ein Rahmen. Bewertet werden am Ende die Inhalte, nicht bloß die Zahl auf der letzten Seite.

Ausnahme: Lesbarkeit

Der wichtigste Grund, ein Artefakt doch im Fließtext zu platzieren, ist die Lesbarkeit.

Das kann sinnvoll sein, wenn:

ein Artefakt sehr erklärungsbedürftig ist

der zugehörige Text direkt daneben stehen sollte

ständiges Blättern oder Springen zwischen Text und Anhang das Verständnis erschwert

Beispiele dafür können sein:

eine kurze, erklärungsintensive Code-Stelle

eine kleine Berechnung oder Formel

eine kompakte Kostenberechnung

eine grobe Zeitplanung

eine Amortisationsrechnung

Dabei bleibt die zweite Daumenregel bestehen:

Ist das Artefakt größer als eine halbe Seite, gehört es trotzdem in den Anhang.

Denn wenn Erklärung und Artefakt ohnehin nicht mehr gemeinsam auf eine Seite passen, geht der Vorteil für die Lesbarkeit wieder verloren.

Artefakte nicht als Seitenfüller verwenden

Artefakte sollten nicht dazu dienen, den Fließtext künstlich aufzublähen, wenn dir sonst Inhalt fehlt.

Wenn große oder unpassende Artefakte ohne echten Grund im Fließtext stehen, kann das bei der Bewertung als Hinweis gesehen werden, dass dort eigentlich zu wenig sinnvoller Textinhalt vorhanden ist. Solche Artefakte werden inhaltlich nicht als Ersatz für fehlende Erklärungen gewertet.

Wichtig dabei:

Es gibt nicht automatisch Punktabzug wegen einer bestimmten Seitenzahl.

Punktabzug entsteht dann, wenn dadurch erkennbare inhaltliche Lücken bleiben.

Artefakte haben einen Zweck

Eine Projektdokumentation sollte nicht aus einer bloßen Sammlung von Artefakten bestehen.

Nicht ausreichend ist zum Beispiel:

Überschrift

ein Satz wie "Ich habe ein UML-Diagramm erstellt, siehe Anhang"

sonst keine weitere Erklärung

Artefakte haben keinen Selbstzweck. Sie sollen zeigen, dass du methodisch gearbeitet hast und dir vor der Umsetzung Gedanken gemacht hast.

Beispiele:

In der Anwendungsentwicklung helfen Klassendiagramme, ER-Modelle oder Architekturskizzen dabei, die Struktur vor der Implementierung zu planen.

In der Systemintegration helfen Netzwerkpläne oder Sicherheitsüberlegungen dabei, Anforderungen und Rahmenbedingungen sauber zu analysieren.

Artefakte sollen also nicht nur für die Prüfung da sein, sondern einen praktischen Nutzen im Projekt haben.

Was in den Fließtext gehört

Im Fließtext sollte stehen:

warum du ein Artefakt erstellt hast

wie du dabei vorgegangen bist

welche Besonderheiten dir dabei aufgefallen sind

wie dir das Artefakt im weiteren Verlauf geholfen hat

was du darauf aufbauend später gemacht hast

Ein gutes Beispiel wäre nicht nur zu schreiben, dass ein Klassendiagramm existiert, sondern zu beschreiben:

welche Klassen notwendig waren

welche Beziehungen oder Abstraktionen sich ergeben haben

welche Erkenntnisse daraus entstanden sind

wie das Diagramm später bei der Implementierung geholfen hat

Das Artefakt selbst kommt dann in den Anhang, der Kontext und die Einordnung gehören in den Fließtext.

Fazit

Die Kernaussage ist:

Artefakte in den Anhang

Erklärungen, Einordnung und Nutzen in den Fließtext

Ausnahmen im Fließtext sind nur dann sinnvoll, wenn kleine Artefakte direkt zum Verständnis beitragen. Für fast alles andere gilt: Anhang.

So nutzt du sowohl den Fließtext als auch den Anhang sinnvoll aus und zeigst nicht nur Ergebnisse, sondern auch dein methodisches Vorgehen.

Links

Permalink zu dieser Podcast-Episode

RSS-Feed des Podcasts

Transkription der gesamten Episode

Automatisch erzeugte Transkription der Episode

[0:20] Heute geht es mal um eines meiner Lieblingsthemen, wenn ich wieder Projektdokumentation lese und bewerten darf. Und zwar um die Platzierung von Artefakten in der Projektdokumentation. Diesen Begriff Artefakt, den benutze ich ganz häufig im Blog, im Podcast, in meinen Videos. Was ist damit gemeint? Kurz zum Einstieg. Ich meine mit Artefakt alles, was in der Dokumentation oder in deiner Präsentation später auch, was kein Fließtext ist. Also Beispiel Projektdokumentation, irgendwelche Diagramme, UML-Sachen, ER-Modelle, Amortisationsrechnung, wenn du die grafisch machst, aber auch Tabellen, zum Beispiel Kostenaufstellung oder deine Zeitplanung. Code natürlich, wenn du Anwendungsentwicklung machst, irgendwelche Pläne, Netzwerkpläne oder Sonstiges oder ein Testprotokoll oder so. Oder auch wenn du Berechnungen machst, irgendwelche Formeln oder Sachen, die nacheinander berechnet werden, zum Beispiel bei der Amortisationsrechnung. Und selbstverständlich auch Screenshots, wenn du Fotos machst aus der echten Welt, solche Dinge, das sind für mich alles Artefakte. Also Dinge, die kein Text sind, wobei, ja, Code ist Text, okay. Aber ich glaube, du verstehst, worauf ich hinaus will. Fließtext im Verhältnis zu alles andere sind Artefakte. Und ich mache es gerne zum Einstieg nochmal, wie in anderen Episoden auch, so ein Too Long Didn’t Read oder Didn’t Here in diesem Fall. Meine Empfehlung ist, pack alle Artefakte in den Anhang. Es gibt wenig Gründe dafür, Artefakte in deinen Fließtext zu packen. Also du schreibst einen Satz, machst dann ein Artefakt da rein und schreibst dann weiter.

[1:48] Daumenregel sollte sein, alles in den Anhang. Und absolute Daumenregel aus meiner Sicht ist, alles was größer ist als eine halbe Seite, auf jeden Fall in den Anhang. So und jetzt gibt es vielleicht ein, zwei kleine Ausnahmen, wo man Artefakte auch in den Fließtext packen sollte oder darf oder vielleicht sogar muss. Da gehen wir gleich nochmal drauf ein. Aber als Daumenregel kannst du schon mal mitnehmen, alle Artefakte in den Anhang, insbesondere wenn sie größer sind als eine halbe Seite.

[2:13] So, jetzt gehen wir mal die Details da durch. Warum ist das so? Warum ist das sinnvoll? Also, vielleicht vorweg, die meisten IHK’n machen irgendwelche Vorgaben für deine Projektdokumentation, was die Seitenzahl angeht. Und das sind meistens Maximalforgaben, also zum Beispiel maximal 15 Seiten Fließtext und 25 Seiten Anhang. So ist es zum Beispiel bei der IHK Oldenburg, wo ich beschäftigt bin. Ganz wichtig vorweg, guck dir unbedingt die Vorgaben deiner IHK an. Es gibt nämlich 79 verschiedene in Deutschland und die machen im Zweifel alle unterschiedliche Vorgaben. Also orientier dich nicht an irgendwas, was du im Internet gehört oder gelesen hast, sondern frag bei deiner IHK nach, wo du deine Note nachher bekommst, was die Vorgaben sind. Ich gehe jetzt mal einfach davon aus, dass es 15 Seiten für Fließdecks sind und 25 für Anhang. So ist es bei uns. Aber das kann stark abweichen. Ich habe teilweise Vorgaben gesehen bis 10 Seiten runter plus nochmal 5 im Anhang oder so. Also wirklich deutlich weniger. Es gibt aber auch nach oben Abweichungen. Also guck einfach nach, was gilt für dich und dann orientierst du dich an diesen Zahlen. Ich gehe jetzt mal von den 15 Seiten aus und dann ist es üblicherweise so, dass du deine Seitenzahl maximal ausreizen möchtest. Dafür habe ich auch eine eigene Episode, einen kleinen Short aufgenommen, verlinke ich auch nochmal in den Shownotes, warum ich dann empfehlen würde, die Seitenzahl auszufüllen. Kurz gesagt, was ist, wenn du nicht alles ausfüllst? Kriegst du eine schlechte Note? Ja, dann hast du deine Chancen, die du hättest, halt nicht genutzt. Du hast zu wenig Inhalt geliefert, kriegst dafür einen Punktabzug. Blöd, ja? Also versuch die Seitenzahl auszunutzen und so gut es geht, alles mit sinnvollen Inhalten zu füllen.

[3:40] Und dann solltest du, wenn du sinnvolle Inhalte hast, sowas wie Lastenpflichtenheft, UML-Diagramme und ich weiß nicht, was du alles erstellen kannst für dein Projekt, auch dazu ein Hinweis in der verlinkten Episode, solltest du genug Inhalt haben, um deine Fließtext-Seiten zu füllen, aber auch um den Anhang zu füllen. Meistens sogar eher für den Anhang noch mehr, allein schon, wenn du was programmierst. Code-Beispiele, da kannst du ganz, ganz, ganz, ganz, ganz viel zeigen und Screenshots und ich weiß nicht mehr. Also normalerweise solltest du keine Probleme haben, um diese Seitenzahl zu erreichen. Es sollte eher ein Problem sein, zusammenzustreichen, um wieder auf die Seitenzahl runterzukommen, wenn du drüber bist. Das ist meine persönliche Einstellung. Wenn das nicht geht bei deinem Projekt, hast du vielleicht ein zu wenig umfangreiches Projekt oder du hast einfach einen Haufen Artefakte vergessen, die in der Prüfung möglicherweise erwartet werden, aber dazu auch mehr in einer anderen Episode. Heute geht es ja darum, wenn du diese ganzen Inhalte hast, wo packst du sie hin?

[4:32] Und ich würde halt sagen, dass du Fließtext locker füllen kannst und den Anhang genauso. Und wenn du jetzt Artefakte in deinen Fließtext packst, dann gehen die ja von der Seitenzahl für deinen Fließtext ab. Also keine Ahnung, du hast 15 Seiten Fließtext und mittendrin hast du aber eine ganze Seite Klassendiagramm. Dann hast du natürlich eine Seite weniger für den Text, weil das Klassendiagramm braucht dir auf, diese eine Seite. Das heißt, du hast also nicht wirklich 15 Seiten Fließtext, sondern nur 14, weil eine Seite davon ist halt ein Klassendiagramm.

[5:01] Und das ist ja blöd, weil auf dieser Seite Fließtext hättest du ja auch noch Inhalte unterbringen können, die jetzt vermutlich fehlen. Und hier auch nochmal, ich habe es in einer anderen Episode auch schon gesagt, wenn ich über Punktabzug oder Notenabzug oder Durchfallen spreche, dann hat das nie etwas damit zu tun, ob am Ende da 14 oder 15 Seiten stehen, sondern es hat immer etwas damit zu tun, dass Inhalte nicht da sind, die erwartet werden. Ja, dass du irgendwas Wichtiges nicht gezeigt hast. Keine Ahnung, wenn du zum Beispiel gar kein Klassendiagramm hast oder gar kein Code in einem Anwendungs-Ermütungsprojekt, würde ich sagen, da fehlt was, weil das würde ich schon ganz gern sehen. Ja, und da hilft es auch nicht, wenn du 15 Seiten Fließtext voll ausgereizt hast, aber du hast trotzdem kein Klassendiagramm gemacht. Und das ist jetzt nur ein Beispiel. Ja, es ist nicht für jedes Projekt ein Klassendiagramm sinnvoll. Es ist nur ein Beispiel. Aber wenn ich es erwarten würde in deinem Projekt, aber du hast es nicht gemacht und dafür trotzdem 15 Seiten geschrieben, dann fehlt mir halt trotzdem was. Ja. Und auch wenn du nur 14 hast und dir fehlt das Klassenlegramm, fehlt mir das Klassenlegramm. Also bitte, häng dich nicht an dieser Seitenzahl auf und denk auch nicht, dass die Prüfer dir Punkte abziehen, nur weil du nicht die richtige Seitenzahl hast.

[6:03] Sondern es geht immer um die jeweils fehlenden Inhalte. Und deswegen versuchen wir die Seiten möglichst mit sinnvollen Inhalten zu füllen und dann aber auch bis zum Maximum, weil sonst vergibst du dir halt die Chance, diese Inhalte zu zeigen.

[6:16] So, also Artefakte im Fließtext, die reduzieren deine verfügbaren Seiten für den Fließtext und das ist schlecht. Deswegen gehören die in den Anhang. Dafür ist auch meistens extra eine Vorgabe für die Anhangseiten gegeben, denn auch da müssen wir uns ein bisschen reduzieren und können ja einfach 100 Seiten Anhang hinterpacken. Ja, das geht einfach nicht. So, jetzt habe ich gesagt, alle Artefakte in den Anhang. Jetzt gibt es eine Sache, die du abwägen musst, und zwar die Lesbarkeit. Du musst dir ja vorstellen, deine Dokumentation wird von Menschen wie mir gelesen, korrigiert. Und die wollen natürlich auch verstehen können. Und wenn du jetzt sehr erklärungsintensive Artefakte in deiner Dokumentation hast, ich nehme mal ein Beispiel, weiß ich nicht, eine halbe Seite Quelltext mit super fancy Algorithmen, wo man wirklich jede zweite Zeile erklären muss, weil man die sonst nicht versteht. Oder du hast ein super kompliziertes Netzwerk-Therakum gezeichnet mit drei Firewalls, mit irgendwelchen Port-Forwardings und weiß der Geier was und du musst da ganz, ganz viel zu erklären. Dann kann es sinnvoll sein, das Artefakt direkt in den Text zu platzieren, weil dann kann ich auf einer Seite, die ich gerade offen habe oder mir sogar ausgedruckt habe, auch das gibt es noch bei Prüfenden im Jahr 2026, überhaupt keine Frage, weil korrigieren mit Rotstift kann man hervorragend auf Papier übrigens. Das hat sich nicht viel geändert in den letzten Jahrzehnten.

[7:30] Deswegen, wenn ich das alles auf einer Seite habe, kann ich das wunderbar auf einen Blick sehen, kann das verstehen, kann zwischen Text und Abbildung hin und her springen und kann das super nachvollziehen. Toll. Habe ich allerdings meinen Erklärungstext auf Seite 5 und mein Artefakt im Anhang auf Seite 27, dann muss ich halt immer hin und her blättern, was gar nicht mal so schlimm ist, das kriegt man schon mal hin, aber wenn Menschen wie ich, die das auf dem iPad zum Beispiel lesen, das dann vergleichen wollen, dann wird es schwierig, weil dann muss ich immer hin und her jumpen im Inhaltsverzeichnis und das dauert jedes Mal ein paar Sekunden, bis ich die Seite gefunden habe und so weiter und das ist einfach nervig. Das heißt, es ist nicht förderlich fürs Verständnis, wenn die Sachen so weit auseinander liegen.

[8:06] Jetzt ist es so, wenn du wirklich sehr erklärungsbedürftige Artefakte hast, kannst du die vielleicht in den Text packen. Da würde ich trotzdem meine zweite Daumenregel ziehen und sagen, wenn das Ding länger ist als eine halbe Seite, packe es trotzdem in den Anhang. warum? Angenommen, das Klassenlehrgramm von eben wäre eine ganze Seite groß, dann passt das ja eh nicht mehr auf die Seite, wo der Erklärtext steht. Also müsstest du sowieso beim Lesen scrollen. Auf Seite 14 ist die Erklärung, auf Seite 15 das Klassenlehrgramm. Ja, super, da muss ich ja trotzdem immer hin und her blättern, beziehungsweise hoch und runter scrollen. Da habe ich ja nichts gewonnen. Das heißt, größere Artefakte auf jeden Fall immer in den Anhang und kleinere und welche, die vielleicht auch wirklich nur sinnvoll sind in Verbindung mit dem Text, keine Ahnung. Deine Kostenberechnung, wo am Ende dann steht, das Projekt hat 2395 Euro gekostet und direkt darüber wäre es dann schön, vielleicht die Formel zu sehen, wie du es berechnet hast, damit ich nicht 20 Seiten hin und her springen muss, um diese winzige Kleinigkeit daraus zu ziehen. Also es gibt so ein paar Sachen, wie zum Beispiel die grobe Zeiteinplanung deiner 40 oder 80 Stunden oder eben deine Amortisationsrechnung, deine Kostenberechnung. Solche Dinge, die kann man auch im Fließtext platzieren. Die sind aber meistens auch nicht sehr lang. Die sind vielleicht eine Viertelseite, vielleicht maximal eine halbe Seite lang. Und wie gesagt, dann greift dann halt meine Regel, dass du das auch nach oben in den Fließtext packen kannst. Aber ansonsten würde ich sagen, alles in den Anhang. Also Lesbarkeit ist aus meiner Sicht der einzige Grund, warum man das in den Fließtext packen sollte.

[9:29] So, und jetzt nochmal gesagt, wenn du diese Fleece-Seiten quasi damit aufblähen möchtest, dass du sie mit Artefakten zukleisterst, weil dir einfach nicht einfällt, was du da an Fleece-Sext noch schreiben könntest.

[9:45] Dann würde ich sagen, tu das lieber nicht. Weil, ganz ehrlich, auch wenn vielleicht der Eindruck entsteht, die Prüfenden sind alle irgendwie alte, weiße Männer, jenseits der 60 und wissen eigentlich gar nicht mehr so genau, was da heute Phase ist in der IT. Ist nicht so. Die Prüfenden sind auch nicht doof. Die sind ja nicht umsonst Prüfende geworden. Haben also mindestens mal selber auch die Prüfung absolviert und sind meistens langjährig irgendwo beschäftigt, in der Ausbildung, Ausbilder oder Geschäftsführer, was auch immer. Also das sind ja keine Vollidionen, die da sitzen. Und wenn ich jetzt eine Doku lese, wo auf jeder zweiten Seite ein großes Bild ist, dann werde ich dir das einfach von der Seitenzahl abziehen. Ganz einfach. Also ich gehe am Ende, wenn ich die Doku gelesen habe, gehe ich den Fließtext durch und ziehe mir alle Artefakte von der Seitenzahl ab, die also mindestens größer als eine halbe Seite sind. Wenn sie quasi sinnfrei sind an der Stelle und nicht erklärungsbedürftig, würde ich sie auch abziehen, wenn sie kleiner als eine halbe Seite sind. Das heißt, ich gucke wirklich alle Fließtextseiten durch, sehe ich ein Artefakt, ziehe ich das ab und am Ende komme ich auf Seitenzahl 12 statt 15, auch wenn die letzte Seitenzahl 15 ist, weil halt einfach drei Seitenartefakte dazwischen waren. Ja, so mache ich das. Und jetzt nochmal zur Erklärung. Das heißt nicht, dass du deswegen jetzt eine Notabzug kriegst oder auch nur ein Prozentpünktchen Abzug bekommst, sondern für mich ist das nur ein Indiz. Ich sehe jetzt, oh, statt 15 Seiten hat er oder sie eigentlich nur 12 oder 13 Seiten gefüllt.

[10:59] Da kann ja dann irgendwo nur noch eine Lücke sein, was vielleicht noch fehlt in dem Projekt. Und dann gucke ich natürlich, welcher Inhalt fehlt denn und dafür gibt es dann den Punktabzug. Also nicht für die reine Seitenzahl. Ich kann es nur nochmal wiederholen. Also, denk nicht, dass die Prüfenden Idioten sind. Die haben normalerweise schon ein paar mehr Dokus gelesen und korrigiert und erkennen solche Tricks natürlich auch.

[11:24] Gut, also orientier dich am eigentlichen Problem, löst das Problem, pack sinnvollen Inhalt in die Doku und fülle deine Seiten nicht mit Rummel auf, mit irgendeinem Müll oder mit irgendwelchen aufgeblähten Artefakten oder damit du auf 15 Seiten kommst. Das funktioniert nicht, weil die Prüfenden das halt dann wieder abziehen, so wie ich zum Beispiel. So.

[11:44] Und dann nochmal vielleicht, weil ich das auch sehr oft sehe, Artefakte, schön und gut, sind auch sehr wichtig, aber deine Dokumentation sollte halt nicht einfach eine reine Ansammlung von Artefakten sein und dein Fiestext dann ausschließlich aus sowas bestehen wie, ja, ich habe ja auch noch ein UML-Diagramm gezeichnet, siehe Anhang. Ja, und dann kommt das UML-Diagramm im Anhang, das ist super, aber Vleecex gibt es dazu dann gar nicht, sondern da steht einfach nur Überschrift Softwarearchitektur und da steht da ein Satz, ich habe auch eine Architekturskizze gemacht, siehe Anhang 5.

[12:11] So, so füllt man den Vleecex nicht, denn Artefakte haben keinen Selbstzweck oder stehen einfach nur so da, sondern du machst sie aus irgendeinem Grund. Du sollst dir zeigen, dass du auch methodisch vorgegangen bist bei deiner Projektdurchführung. Und insbesondere mal bei der Softwareentwicklung, da fange ich halt nicht einfach an zu programmieren, sondern mache ich mir erst mal Gedanken, was ist denn vielleicht mit meiner Architektur? Welche Komponenten könnte es denn geben? Wie möchte ich die abstrahieren? Erzähl mal. Und als Fisi das Gleiche, da sage ich nicht einfach, ja, ich installiere jetzt hier mal die Firewall, dann gucken wir mal, sondern du musst erst mal analysieren, welcher Traffic muss da durch, welche Ports müssen freigegeben werden, was ist mehr Security und tralala. Das heißt, bevor du am Ende das Ding wirklich einbaust, hast du dir hoffentlich genug Gedanken im Vorfeld schon gemacht. Damit das am Ende auch funktioniert. Und genauso ist es bei der Softwareentwicklung ja auch. Das heißt, diese Artefakte, die haben einen Sinn. Ich zeichne ein ER-Modell nicht einfach nur für die Prüfung, weil die Prüfenden das sehen wollen, sondern weil mir das bei der Arbeit hilft. Wenn ich anfange zu programmieren und weiß noch nicht mal, welche Daten ich abbilden muss. So kann ich doch nicht vorgehen. Ich brauche doch ein Zielbild, wo ich hin will. Wie sollen meine Tabellen aussehen, meine Klassen in der Objektorientierung? Was gibt es denn? Woran muss ich denn denken? Welche Besonderheiten gibt es? Dafür sind die Artefakte da. Die sollen dir helfen. Und das sollst du auch in deiner Projektdokumentation und später in der Präsentation zeigen, dass die dir geholfen haben und dass du die absichtlich gemacht hast und nicht einfach nur gezeichnet hast, weil du ja auch noch eine Prüfungsleistung abgeben musst. Das heißt, die sind immer in einen Kontext zu setzen.

[13:29] Und im besten Fall beschreibst du diesen Kontext im Fließtext. Das heißt, anstatt zu sagen, ich habe hier ein Klassendiagramm, siehe Anhang, sagst du, bevor ich angefangen habe zu programmieren, habe ich mir Gedanken gemacht, welche Klassen ich brauche. Ich habe das Ganze in einem Klassendiagramm modelliert. Dabei ist mir schon aufgefallen, oh, hier gibt es aber eine Vererbungsbeziehung. Oder hier habe ich ein Interface eingezogen, weil die Abstraktion hier sinnvoll war. Und analog zum Netzwerkplan. Oh, hier ist mir aufgefallen, das ist ein ganz anderes Subnet. Da musste ich noch einen Router dazwischen setzen. Oder weiß der Geier was. Das heißt, so etwas sieht man ja in einem Diagramm viel offensichtlicher, als wenn man einfach anfängt und dann merkt, oh, habe ich gar nicht daran gedacht. So wollen wir nicht Software entwickeln, so wollen wir keine Systeme planen. Da brauchen wir diese Artefakte.

[14:07] Wie die dir geholfen haben, wie du die erstellt hast, was vielleicht die Besonderheiten an diesem konkreten Artefakt sind. Das sind Dinge, die du im Fließtext beschreiben musst, weil die kann man an dem Artefakt alleine nicht erkennen. Ich gucke mir dein Klassendiagramm an und denke mir, ja, das ist ein Klassendiagramm. Aber was hast du da mitgenommen? Was sind die Besonderheiten? Wie bist du darauf gekommen? Das ist etwas, wofür der Fließtext da ist. Das heißt, reine Artefaktsammlung, siehe Seite 15, bitte nicht machen, sondern vernünftige Erklärungen im Fließtext. Zumindest meine Herleitung und vielleicht auch einen Ausblick, was du damit dann getan hast. Klassendiagramm ist immer mein Lieblingsbeispiel. Ich zeichne eins, um dann später in der Implementierungsphrase mich daran zu orientieren und die Klassen zu programmieren. Dann ergibt das auch einen Sinn. Du hast das Klassendiagramm nicht einfach nur gemalt, sondern du hast es auch benutzt, um darauf aufbauend etwas anderes zu machen. Und im besten Fall ist dir das dann leichter gefallen. Es ging schneller oder war einfach besser, als hättest du das Diagramm nicht gezeichnet. In diese Richtung wollen wir was im Fließtext lesen. und dann gerne natürlich das Artefakt, aber eben halt im Anhang.

[15:05] So, das war mein Take, glaube ich, zu den Artefakten und wo die hingehören und warum du überhaupt welche machst. Und jetzt nochmal als Fazit für heute. Daumenregel nochmal zum Mitnehmen. Alle Artefakte in den Anhang packen, insbesondere wenn sie größer sind als eine halbe Seite. Dann auf jeden Fall. Dann gibt es eigentlich keinen Grund, die in den Fließtext zu packen. Es gibt wenige Ausnahmen, die ich ein bisschen aufgeführt habe. Vielleicht eine Kostenberechnung, eine Amortisationsrechnung, ein paar Formeln oder so etwas oder eine Zeitplanung, die grobe Zeitplanung. Das kann man vielleicht im Fließtext lassen, aber für fast alle anderen Artefakte würde ich sagen, immer einen Anhang. Bäm.

[15:41] Wichtig wäre, dass du die dann trotzdem in deinem Fließtext referenzierst, dass die Artefakte nicht einfach so im Anhang stehen und dann wundert man sich auch, Mensch, der hat ja auch ein Klassenergaben gezeichnet. Schön, dass ich davon gar nichts gelesen habe im Fließtext. Sondern die müssen natürlich alle referenziert und im besten Fall auch erklärt und eingeordnet werden. Was haben sie dir gebracht? Warum hast du das gemacht? Was hast du vielleicht aufbauen darauf später gemacht? Das gehört dann in den Fließtext dazu. Also Artefakte in den Anhang, Erklärungen, Einordnungen, Besonderheiten in den Fließtext. Und so kannst du auch locker, locker, locker deine Vorgaben füllen, was den Fließtext angeht und was den Anhang angeht. Also Seiten, leere Seiten, beziehungsweise Seiten, die du nicht ausgenutzt hast, müssen meiner Meinung nach nicht sein. Du kannst genug Inhalte produzieren, die dann aber auch wirklich einen Mehrwert für den Prüfenden bieten und dir dann hoffentlich auch eine gute Abschlussnote bestellen. Darum geht es ja am Ende.

[16:29] Also das war es zum Thema Artefakte in der Projektdokumentation. Ich hoffe, es hat dir ein bisschen geholfen. Ich wünsche dir auf jeden Fall viel Erfolg für deine Projektdokumentation und bis zum nächsten Mal.

Um eine sinnvolle Anzahl der Seiten der Projektdokumentation geht es in der neunten Episode der Shorts des IT-Berufe-Podcasts.

Ich würde dir bzgl. der Anzahl der Seiten deiner Projektdokumentation raten, dich immer zuerst an den konkreten Vorgaben deiner IHK zu orientieren, weil Umfang und Regeln je nach IHK unterschiedlich sein können. Die vorgegebene Seitenzahl ist in der Regel eine Obergrenze, die du nicht überschreiten solltest, gleichzeitig solltest du den verfügbaren Platz möglichst mit sinnvollen Inhalten nutzen, weil zu wenig Text meist nicht wegen der Seitenzahl, sondern wegen fehlender Inhalte zum Problem wird. Für mich gilt deshalb: nicht künstlich aufblasen, aber Fließtext und Anhang so gut wie möglich mit bewertbaren, fachlich passenden Inhalten füllen.

Inhalt

TL;DR: Schreib exakt so viele Seiten in deiner Projektdokumentation, wie es deine IHK erlaubt, und nutze den maximalen Umfang möglichst sinnvoll aus, ohne ihn zu überschreiten.

Erst auf die Vorgaben deiner IHK schauen

In Deutschland gibt es viele verschiedene IHKen und sie können bei der Projektdokumentation unterschiedliche Vorgaben haben. Deshalb solltest du dich nicht auf Aussagen aus Social Media oder aus "dem Internet" verlassen, sondern immer die Unterlagen deiner eigenen IHK prüfen.

Typische Unterschiede können sein:

erlaubte Seitenzahl im Fließtext

Regelungen zum Anhang

Umgang mit Verzeichnissen

Vorgaben zu Schriftgröße und Schriftart

Pflicht zu Deckblatt oder bestimmten Bestandteilen

Mein Rat ist deshalb: Schau in die Merkblätter, Handreichungen oder Vorgaben deiner IHK und orientiere dich genau daran.

Die Seitenzahl ist normalerweise eine Maximalvorgabe

Die vorgegebene Seitenzahl meist eine Obergrenze. Es geht also nicht darum, die Seiten zwanghaft vollzumachen, sondern darum, nicht darüber zu liegen.

Der Hintergrund dafür ist aus meiner Sicht vor allem organisatorisch und fair:

Prüfende müssen viele Dokumentationen in begrenzter Zeit lesen

umfangreiche Dokumentationen sind in der Praxis schwer zu bewerten

alle Prüflinge sollen unter vergleichbaren Bedingungen bewertet werden

Als typischen Rahmen gibt es meist 10 bis 20 Seiten Fließtext, je nach IHK. Oft gibt es zusätzlich eine eigene Begrenzung für den Anhang.

Ein Beispiel aus Oldenburg:

15 Seiten Fließtext maximal

25 Seiten Anhang maximal

Verzeichnisse und bestimmte formale Bestandteile zählen dabei nicht mit

Zu viele Seiten können zu Abzügen führen

Wenn du die maximale Seitenzahl überschreitest, hast du die Vorgaben nicht eingehalten. Ich vergleiche das gerne mit einem Budget, das überschritten wird: Wenn 15 Seiten erlaubt sind, dann sind 16 eben formal zu viel.

Ich sage aber auch:

wegen einer kleinen Überschreitung fällt man nicht automatisch durch

die Folgen hängen von Bewertungskriterien und dem jeweiligen Prüfungsausschuss ab

formale Fehler führen eher zu kleineren Abzügen als zu einem kompletten Duchfallen

Trotzdem bleibt mein Hinweis eindeutig: Überschreite die erlaubte Seitenzahl nicht.

Zu wenige Seiten sind nicht direkt das Problem

Ich betone hier nochmal, dass niemand allein deshalb Punkte abzieht, weil du weniger Seiten abgegeben hast als maximal erlaubt. Eine Dokumentation mit weniger Seiten ist formal erst einmal in Ordnung.

Das eigentliche Problem ist für mich etwas anderes:

Wenn du deutlich weniger schreibst, fehlen oft wichtige Inhalte.

Der Punktabzug kommt dann nicht wegen der Seitenzahl, sondern wegen nicht dokumentierter Inhalte.

Mein Beispiel dazu: Wenn ich bei einem Softwareprojekt ein Klassendiagramm erwarten würde und es fehlt, dann ziehe ich dafür Punkte ab. Nicht, weil noch freie Seiten übrig waren, sondern weil ein inhaltlich sinnvoller Bestandteil fehlt.

Mein praktischer Rat: Nutze den verfügbaren Platz aus

Ich empfehle dir, die erlaubte Seitenzahl möglichst vollständig zu nutzen, weil die Wahrscheinlichkeit hoch ist, dass sonst etwas Relevantes fehlt. Das heißt aber ausdrücklich nicht, dass du die Seiten mit beliebigem Material oder KI-generiertem Fülltext aufblasen sollst.

Wichtig ist mir dabei:

keine inhaltsleeren Wiederholungen

keine künstlich verlängerten Beschreibungen

keine sinnlosen Diagramme ohne Aussagekraft

stattdessen nur Inhalte, die einen fachlichen Mehrwert haben und bewertet werden können

Wie ich auf Seitenzahl und Inhalt schaue

Beim Lesen von Projektdokumentationen betrachte ich Artefakte im Fließtext gedanklich anders als reinen Fließtext. Dazu zähle ich zum Beispiel:

Abbildungen

Tabellen

Diagramme

Codeschnipsel

Berechnungen

Wenn mitten im Fließtext viele solcher Elemente stehen, ist das für mich ein Hinweis darauf, dass der eigentliche beschreibende Text kürzer ausfällt. Das führt nicht automatisch zu einem Abzug, aber es kann ein Indiz sein, dass Inhalte eventuell zu knapp dargestellt wurden. Entscheidend bleibt für mich immer der Inhalt, nicht die nackte Seitenzahl.

Was du in eine Projektdokumentation aufnehmen könntest

Hier kommt eine ganze Reihe von Inhalten, die in einem typischen Projekt der Fachinformatiker:innen, besonders in der Anwendungsentwicklung, vorkommen können. Vieles davon gilt auch für andere IT-Berufe.

Anforderungen

Anforderungsermittlung

Lastenheft

Pflichtenheft

User Storys

Product Backlog

Architektur und technische Modelle

Architekturskizzen

UML-Diagramme

Klassendiagramme

Sequenzdiagramme

Zustandsdiagramme

Komponentendiagramme

Deployment-Diagramme

Infrastruktur und Systemdarstellung

Netzwerkpläne

Server-Erreichbarkeit

Ports und technische Zusammenhänge

Datenmodellierung und Schnittstellen

ER-Modelle

relationale Tabellenmodelle

JSON-Strukturen

OpenAPI-Beschreibungen bei REST-APIs

Prozesse und Abläufe

dokumentierte oder optimierte Prozesse

Modellierung mit BPMN

EPK

Aktivitätsdiagramme

Umsetzungsnachweise

Quellcode aus Produktivcode oder Testcode

Screenshots

Konfigurationsdateien

Fotos von umgesetzten Arbeiten

Projektorganisation

Vorgehensmodell wie Scrum, Wasserfall oder Kanban

Beschreibung des Entwicklungsprozesses

Ticket-System

Code-Review

Zusammenarbeit mit anderen Beteiligten

organisatorische Abläufe

Planung und Wirtschaftlichkeit

Zeitplanung für die 40 bzw. 80 Stunden

Ressourcenplanung

detaillierte Tabellen

Kostenkalkulation

Amortisationsrechnung

Gegenüberstellung von Kosten und Einsparpotenzial

Mit dieser Liste will ich zeigen, dass bei einem normalen Projekt schnell viele sinnvolle Inhalte zusammenkommen können und 15 Seiten deshalb durchaus knapp werden können.

Meine abschließende Motivation für dich

Ich gebe dir am Ende noch einen Gedanken mit: Wenn du eine schlechte Note bekommst oder sogar durchfällst, obwohl du noch freie Seiten gehabt hättest, wirst du dich möglicherweise fragen, ob zusätzliche sinnvolle Inhalte den Unterschied gemacht hätten.

Deshalb mein Fazit:

halte die Maximalvorgabe deiner IHK ein

überschreite sie nicht

nutze den verfügbaren Platz aber möglichst aus

fülle ihn nur mit sinnvollen, bewertbaren Inhalten

Für mich ist genau das der sinnvolle Weg, damit deine Projektdokumentation zeigt, was du in deiner Ausbildung gelernt hast und was du im Projekt tatsächlich geleistet hast.

Links

Permalink zu dieser Podcast-Episode

RSS-Feed des Podcasts

Inhalte der Projektdokumentation

Gliederung der Projektdokumentation (Teil 1)

Transkription der gesamten Episode

Automatisch erzeugte Transkription der Episode

[0:20] Heute geht es um ein Thema, was immer wieder für Aufsehen sorgt oder Aufregung auf, vor allem im Internet, gerade bei TikTok, unter meinen letzten Videos, die ich gerade gepostet habe, während ich das hier aufnehme. Und zwar zum Thema Seitenzahlen in der Projektdokumentation bei dem Abschlussprojekt der IT-Berufe. Und ja, Kernfrage, die ich heute beantworten will, ist, wie viele Seiten sollte meine Projektdokumentation haben? Also vor allem Fließtext, aber auch Anhang, wie viele Seiten sind da sinnvoll? Und ich mache mal so ein Too-Long-Din’t-Read zum Einstieg. Wenn du nicht weiterhören willst als hier, schreib einfach genauso viele Seiten voll, wie deine IHK dir erlaubt. Das war’s. Und jetzt kommen wir kurze Erklärungen, warum das so ist. Fangen wir vielleicht mal ganz vorne an. Deine IHK erlaubt dir was? Hä? Ja, denn wir erinnern uns, wir haben in Deutschland 79 verschiedene IHKen. Und die machen für ihre Abschlussprojekte, für die IT-Brufe alle eventuell unterschiedliche Vorgaben. Einige machen auch keine Vorgaben oder haben einfach nichts online oder was auch immer, machen stillschweigend irgendwelche Vorgaben. Aber erstmal ist Fakt, wir haben verschiedene IHK’en und die machen potenziell unterschiedliche Vorgaben, was den Umfang einer Projektdokumentation angeht. Das heißt von, ich glaube, 10 bis 20 Seiten Fließtext habe ich schon verschiedene Vorgaben gesehen.

[1:34] Einige nehmen den Anhang mit dazu, andere nicht. Verzeichnen es raus oder doch nicht. Und es gibt überall die Möglichkeit für jede IHK, das individuell festzulegen. Es ist nicht deutschlandweit standardmäßig überall gleich. Das schon mal vorweg. Wie bei ganz vielen anderen Sachen auch übrigens zur Abschlusspräsentation und Projektdokumentation. Immer erstmal gucken, was die eigene IHK vorgibt. Weil das kann teilweise sehr krass unterschiedlich sein zu irgendwas, was du irgendwo anders im Internet liest oder gehört hast. Also guck immer, was deine IHK dir vorgibt. Daran musst du dich orientieren und nicht an irgendwas, was du irgendwo mal gehört hast bei TikTok, Instagram oder YouTube. Ja, deine IHK vergibt, nein, die IHK gibt dir nicht die Note, der Prüfungsausschuss gibt dir die Note, aber die orientieren sich natürlich an den Vorgaben der jeweiligen IHK. Also bitte erstmal darauf gucken. Und im einfachsten Fall guckst du auf der Website deine IHK, da gibt es normalerweise Merkblätter, Handreichungen, Vorgaben, was auch immer, zur Projektarbeit in den IT-Berufen. Ja, es gibt Projektarbeiten auch in anderen Berufen. Deswegen guck explizit nach den für deinen Beruf und nicht nach irgendwelchen. Vielleicht gibt es auch nur allgemeine Vorgaben. Also kurz gesagt, guck bei der IHK und recherchiere und find raus, was für deine Projektarbeit gilt. Punkt. Das ist erstmal das Allerwichtigste und daran orientierst du dich.

[2:48] Und wenn es eine Vorgabe gibt, dann steht da meistens sowas drin wie, wie die Schriftgröße sein soll, die Schriftfamilie, zum Beispiel Areal oder sonst irgendwas, ob es Verzeichnisse geben muss oder nicht, ob es ein Deckblatt geben muss und da gibt es ganz, ganz viele Vorgaben und insbesondere wird dort auch eben oft die Seitenzahl vorgegeben.

[3:07] Warum? Wenn ich mich an meine Ausbildung erinnere, und die ist jetzt echt lange her. Also ich habe meine Abschlussprüfung gemacht 2006, glaube ich. Also wenn ich das jetzt hier gerade aufnehme, 20 Jahre her. Und damals gab es bei meiner IHKF keine Vorgaben. Und meine Projektdokumentation war über 100 Seiten lang.

[3:25] Ganz viel Quelltext dran und noch und nöcher Datenverarbeitungskonzept allein, glaube ich, 10 Seiten. Also das war ein Riesending. Und wenn ich mir vorstelle, dass das irgendein Prüfender lesen und bewerten muss in endlicher Zeit, Kostenfrei in seiner Freizeit als Ehrenamt. Das ist echt nicht darstellbar, wenn man dann so wie wir zum Beispiel jetzt in diesem Prüfungsdurchgang über 100 Prüflinge haben. Es ist nicht möglich, das alles noch irgendwie zu stemmen. Deswegen muss man das reduzieren. Es geht also bei diesen Vorgaben nicht darum, dass du diese Seiten füllen musst, sondern es sind eigentlich immer maximal Vorgaben, also maximal 10 Seiten zum Beispiel. Das heißt nicht, dass du die komplett auffüllen musst, aber du darfst nicht drüber liegen, weil dann wird es halt auch irgendwann ein Problem für die Prüfenden und dann wäre es auch unfair, wenn der eine 10 Seiten abgibt, der andere aber 30 und beides ist okay. Ja gut, da kannst du ja ausrechnen, dass bei 30 Seiten irgendwie mehr bei rumkommt als bei 10. Überraschung. Deswegen gibt es immer eigentlich eine Maximalvorgabe und oft liegen die für normalen Fließtext der Projektdokumentation zwischen 10 und 20 Seiten. Vielleicht gibt es auch welche, die noch mehr, noch weniger vorgeben. Dann schreib es mir gerne als Kommentar. Würde mich natürlich interessieren. Ich kenne auch nicht alle 79 IHK-Vorgaben, aber üblicherweise so 10 bis 20 Seiten, davon kann man ausgehen.

[4:38] Und zusätzlich gibt es dann manchmal oder meistens auch noch weitere Vorgaben für den Anhang. Also hier wird meistens getrennt, Fließtext plus Anhang sind nochmal separate Seiten. Als Beispiel, und daran werde ich mich eigentlich auch immer orientieren jetzt im weiteren Verlauf, bei der IHK Oldenburg, da bin ich ja nun mal prüfender, da haben wir 15 Seiten maximal für den Fließtext plus 25 Seiten maximal für den Anhang. Das heißt insgesamt 40 Seiten für die Projektdokumentation und nicht mit drin sind da dann zum Beispiel noch die Inhaltsverzeichnisse und Tabellenverzeichnisse und alles, was davor halt noch kommt. Und das Deckblatt der IHK und so, das wird alles nicht berechnet. Ab Seite 1, wo du mit der Einleitung startest, 15 Seiten fließt, und danach kommt der Anhang und alles, was da drin ist, dafür hat man 25 Seiten. So, da gehe ich jetzt mal von aus. Andere IHK machen das ähnlich. Wie gesagt, plus, minus, X Seiten, alles möglich.

[5:28] So, es geht also nicht darum, diese Maximalvorgabe auf Teufel komm raus zu füllen, sondern nur, dass du nicht drüber liegst. Denn wenn du drüber liegst, dann müsste dir ein Prüfender dafür auch einen Punktabzug geben, weil du einfach nicht in der Lage warst, diese Vorgaben einzuhalten.

[5:41] Wenn man dir sagt, du musst, auch ein beliebtes Beispiel aus einem meiner Videos, du musst für 100 Euro Brötchen kaufen, aber kaufst welche für 110, dann kannst du am Ende nicht sagen, Chef hat aber 110 gekostet. Wenn die Vorgabe, also dein Budget 100 war, dann kannst du nicht 110 ausgeben. Das funktioniert nicht. Und hier ist es genauso, wenn die Prüfungsvorgabe ist maximal 15 Seiten und du gibst 16 ab, dann hast du die Vorgabe nicht eingehalten. Das wäre vergleichbar mit, du hast die Schriftgröße, den Seitenabstand oder was auch immer nicht eingehalten. Dafür muss es halt einen Punktabzug geben. Machen die Prüfer das immer? Wird man bei 15,5 Seiten gleich eine Noteabzug bekommen? Nein, natürlich nicht. Es gibt Bewertungskriterien, Bewertungsmatrizen, wo genau drin steht bei einigen IHK, wofür man wie viele Punkte kriegen kann oder auch nicht kriegen kann. Und für formale oder formelle Gestaltung gibt es bei ganz vielen IHK eine eigene Kategorie und das sind dann vielleicht, weiß ich nicht, 10% der Note. Weil natürlich kommt es bei der Projektdokumentation beim gesamten Projekt auf den Inhalt an und da wird es, wenn überhaupt, einen Abzug für irgendwelche Seitenzahlen oder so geben im unteren Prozentbereich. Da wird man sicherlich nicht eine Note dafür abziehen, wenn du eine Seite zu viel hast. Aber es muss im Vergleich zu jemandem, der die Seitenzahl eingehalten hat, ja irgendwie schlechter bewertet werden. Das ist doch sonst nicht mehr fair den anderen gegenüber, die sich an die Vorgaben gehalten haben. Das kann man ja so nicht machen. Also grundsätzlich abzugsfähig ist das, wenn du zu viele Seiten hast. Heißt das, dass du deswegen sofort durchfällst? Nein.

[7:11] Könnte man dich dafür durchfallen lassen? Ja, weil du hast die Vorgaben halt nicht eingehalten. Du kannst auch nicht sagen, ich habe 100 Stunden programmiert statt 80 als Anwendungsmeckler und kriegst dafür eine 1. Das funktioniert ja nicht, weil alle anderen haben 80 gebraucht und du 100. Sorry, Vorgaben nicht eingehalten. Also, muss man immer genau gucken, kriegt man jetzt wegen, wie gesagt, einer Zeile mehr eine Note, Punkt, Absatz, oder fällt durch? Eher nicht, aber die Chance ist halt da und theoretisch, formal, könnte man nicht durchfallen lassen dafür. Also, halt die obere Seitenzahl auf jeden Fall ein und schreib nicht mehr als erlaubt. Das wäre schon mal ganz wichtig.

[7:44] So, jetzt ist aber bei vielen Projektdokumentationen, die ich so lese und gelesen habe in der Vergangenheit, eher das Problem, dass sie zu wenig in Anführungszeichen füllen. Das heißt, in Anführungszeichen, in Anführungszeichen, zu wenig Seiten füllen. So, und zu wenig in Anführungszeichen, weil das ist ja nur eine Maximalvorgabe. Also du könntest auch eine Doku abgeben mit einer Seite, wenn du maximal 15 schreiben darfst. Alles okay. Das Problem, was jetzt nur daraus folgt, ist, wahrscheinlich ist auf der einen Seite nicht der gleiche Inhalt wie in einer anderen Doku mit 15 Seiten. Ich meine, das sollte offensichtlich sein, dass du keine so gute Projektarbeit dokumentieren kannst, wenn du einfach deutlich weniger Text ablieferst. Das funktioniert nicht. Deswegen ist mein Problem mit Dokus, die zu wenig Seiten haben, nicht, dass sie zu wenig Seiten haben, sondern dass einfach Inhalte fehlen, die auf diesen Seiten stehen würden. Und das bringt auch immer ganz viel durcheinander. Oder es ist dann so, wird jetzt hier schon eine Note abgezogen, wenn ich zwei Seiten zu wenig habe? Nein, dafür kriegt niemand eine Note abgezogen. Es ist ja, die Vorgaben sind eingehalten, dafür kann ich dir gar nichts abziehen. Das Problem ist, wenn du Inhalte nicht lieferst, die du aber hättest liefern können auf diesen fehlenden zwei Seiten. Dafür gibt es einen Punktabzug.

[8:51] Simples Beispiel, ich erwarte bei einer Programmieraufgabe ein Klassendiagramm und du hast keins drin. Dafür aber noch eine Seite frei bis zu deinen 15 erlaubten Seiten. Tut mir leid, dann ziehe ich dir einen Punkt ab, aber nicht für die fehlende Seite, sondern für das fehlende Klassendiagramm. So wird ein Schuh draus. Also kein Prüfender wird dir irgendwie einen Punkt abziehen, weil du zu wenig Text geschrieben hast, sondern es geht immer um den Inhalt, den du nicht geschrieben hast und nicht präsentiert hast. Darum geht es.

[9:16] Also deswegen allein schon mein Vorschlag, nutz immer die ganze Seitenzahl aus, die du zur Verfügung hast, weil sonst hast du sehr wahrscheinlich irgendwas, was dir fehlt einfach.

[9:26] So, und bitte verstehe das jetzt nicht so, dass du diese Seiten dann auffüllst mit Schrott, einfach nur, um auf die 15, 10 oder 20 zu kommen. Darum geht es nicht. Und vor allem bitte im Zeitalter von KI, generiere da nicht irgendeinen Schrotttext, nur um die Seiten zu füllen und der wird dann super umfangreich und ausschweifend und 37 Mal wiederholt, sondern du sollst natürlich sinnvolle Inhalte liefern. Also was zu deiner Arbeit beigetragen hast, was du gemacht hast, was bewertet werden kann. Sinnvolle Artefakte, Diagramme, die irgendwie auch einen Mehrwert bringen. Das sollst du da reinpacken und nicht einfach generierten Fließtext, wo du einfach nochmal ein Bild beschreibst, so nach dem Motto. Das ist hier nicht das, was gemacht werden soll, sondern du sollst sinnvolle Inhalte da reinpacken. Und ich habe gleich auch noch eine Liste, die man durchgehen kann für so ein übliches Projekt, bezogen auf Einwilligungsentwicklung, aber viele Inhalte gelten auch für alle anderen IT-Berufe, was man alles so in eine Doku packen könnte, damit du mal einen Eindruck davon hast, warum vielleicht auch 15 Seiten sogar schon knapp werden, wenn man ein entsprechend normales, umfangreiches Projekt hat.

[10:24] So, ich persönlich mache es tatsächlich so, wenn ich Projektarbeiten jetzt durchlese und korrigiere, dass ich alle Artefakte, die ich irgendwo noch zwischendrin finde in den Fließtextseiten, dass ich die von der Seitenzahl abziehe. Was meine ich mit Artefakten? Also zum Beispiel Abbildung oder Tabellen, Amortisationsrechnung, Code, Schnipsel, was auch immer. Also alles, was kein Fließtext ist, das ist bei mir Artefakte. Und da gehe ich die Doku wirklich durch. Und wenn ich da so eine Seite Klassendiagrammen mitten im Fließtext habe, dann wird das von der Seitenzahl abgezogen. Und dann gucke ich am Ende, oh, sind 13 Seiten gewesen. Okay, daraus folgert ja jetzt noch nicht, dass ich eine Note abziehe oder gar einen Punkt. 13 ist ja kleiner als die erlaubten 15, also passt das alles. Aber das ist für mich nochmal so ein Indiz, wenn ich jetzt sehe, oh, 13 Seiten statt der erlaubten 15, da ist ja die Chance recht hoch, dass irgendetwas fehlt. Und dann gucke ich natürlich nochmal hin, was hätte denn hier noch beschrieben werden können? Ist irgendwas ziemlich knapp oder unverständlich etc.? Und das ist für mich so ein Indiz, um nochmal genauer hinzugucken. Aber bitte nicht falsch verstehen, nur weil jemand 13 Seiten abgibt, mache ich in keinster Weise irgendeinen Punktabzug daran fest, sondern es geht immer um den Inhalt. Punktabzug höchstens, wenn es zu viele Seiten sind. Ich kann mich nur nochmal wiederholen.

[11:34] So, und jetzt würde ich mal überlegen, wenn du Schwierigkeiten hast, deine 15 oder 10 oder 20 Seiten, also die Vorgaben zu füllen, woran könnte das denn liegen? Vielleicht ist dein Projekt tatsächlich einfach nicht umfangreich genug, sollte eigentlich ausgeschlossen sein, dadurch, dass dein Projektantrag ja genehmigt wurde und Prüfende da schon drauf geguckt haben. Also normalerweise sollten die Projekte umfangreich genug sein, sonst wären sie nicht genehmigt worden. Aber vielleicht hast du ja einfach Sachen vergessen, die zu so einem Projekt üblicherweise dazugehören. Das hattest du aber vielleicht gar nicht auf dem Zettel oder man hat dir das nie gesagt. Und deswegen habe ich mal so ein paar Punkte hier auf der Liste, was du in einem üblichen Projekt für Anwendungsentwicklerinnen durchaus unterbringen könntest. Und gefühlt die Hälfte davon gilt auch für alle anderen IT-Berufe. Ich mache nur mal ein paar Beispiele. Irgendwie musst du Anforderungen erfassen. Was soll überhaupt in einem Projekt gemacht werden? Und das müssen übrigens alle IT-Berufe. Das heißt, es gibt irgendeine Form von Anforderungsermittlung. Sei es zum Beispiel ein Lastenheft, ein Pflichtenheft, User Stories, wie ein Product Backlog, wenn du Bock hast auf Scrum oder was auch immer. Irgendwo schreibst du Anforderungen auf, die kannst du da reinnehmen.

[12:32] Dann gibt es vielleicht für die Softwareentwicklung Architekturskizzen, UML-Diagramme, Klassendiagramme, Deployment-Diagramme, Komponentendiagramme. Das kann man wunderbar für Softwareentwicklung zeigen. Bei Fizis gibt es da vielleicht einen Netzwerkplan. Wo steht die Firewall, auf welchen Ports ist der Server erreichbar und was auch immer. Dann haben wir natürlich sowas wie Klassendiagramme, wenn du tiefer in den Code rein willst, Sequenz-Diagramme oder Zustandsdiagramme, wenn dein System Zustände hat. Also alles, was die UML hier gibt. Du kannst Datenbanken modellieren mit ER-Modell oder relationalem Tabellenmodell oder eine JSON-Struktur als Open API, wenn es REST API ist, dokumentieren oder modellieren oder was auch immer. Du hast vielleicht irgendwelche Prozesse, die du optimieren willst. Die müssen dokumentiert werden, die müssen vielleicht modelliert werden mit.

[13:17] BPMN oder einer EPK oder einem Aktivitätsdagramm aus der OML. Du hast, wenn du programmiert hast, irgendwelche Quelltexte von Produktivcode, von Testcode. Du hast Screenshots sicherlich. Du hast vielleicht Config-Files, wo du was angepackt hast. Du hast, weiß ich nicht, am Ende ein Foto gemacht von der Appliance-Firewall, die du in den Server-Rack eingebaut hast. Was auch immer du als Projekt gemacht hast. Also irgendwelche Nachweise, dass du es auch wirklich getan hast. Fotos, Screenshots, wie auch immer. Du hast irgendeine Form von Projektmanagement gemacht, einen Entwicklungsprozess, vielleicht hast du Scrum gemacht oder Wasserfall oder Kanban oder was auch immer, aber auch dazu kannst du Inhalte liefern, vielleicht ein Foto vom Kanban-Board, vielleicht einfach eine Beschreibung des Prozesses, wie ihr mit eurem Ticketsystem arbeitet, wer bei dir einen Code-Review gemacht hat, mit wem du zusammen den Server installiert hast, wer deine Rechnung freigegeben hat, was auch immer, irgendwas, was zum Organatorischen dazugehört.

[14:11] Und ganz sicher hast du in jedem Projekt, egal welcher IT-Beruf, eine Zeitplanung gemacht. Du hast deine 40 oder 80 Stunden aufgeteilt. Du hast eine detaillierte Aufnahme der nötigen Ressourcen gemacht. Du hast die Zeiten runtergebrochen mit einem schön ausgearbeiteten Plan in einer Tabelle, die du irgendwo unterbringen kannst. Und natürlich hast du auch deine Kosten kalkuliert und eine Amortisationsrechnung gemacht. Mit Kosten versus Einsparungspotenzial und ich weiß nicht was. Ein schönes Diagramm mit so einer Amortisationsrechnung, wo sich irgendwo die Linien dann kreuzen und so weiter. Also alles das sind schon mal Themen, die mir so spontan einfallen, die quasi in jedem Projekt untergebracht werden können. Und dann siehst du vielleicht, oh, da könnten 15 Seiten aber ja tatsächlich schon mal knapp werden, wenn du zu allem auch noch ein bisschen was schreibst, anstatt einfach nur das Artefakt einzubauen.

[14:55] So, und ich glaube, das war es jetzt von mir als letzte Motivation, nochmal darüber nachzudenken, die Seiten zu füllen. Was wäre, wenn du jetzt eine schlechte Note bekommst oder vielleicht sogar durchfällst in deiner Projektarbeit und hättest am Ende aber noch Platz gehabt, um was zu schreiben? Du hättest also noch Seiten übrig. Du hattest 15 als Vorgabe, hast nur 10 gefüllt und jetzt fällst du durch die Prüfung. Was wirst du dich dann dein Leben lang oder vielleicht auch nur bis zur nächsten Prüfung in einem halben Jahr fragen? Hätte ich es geschafft, wenn ich noch die fünf Seiten gefüllt hätte? Wenn ich hier noch den einen Text hinzugefügt hätte, dieses eine Testprotokoll, das eine Klassendiagramm, hätte ich dann vielleicht bestanden?

[15:30] Du weißt es nicht. Du hättest es vielleicht geschafft, aber du hast es leider nicht genutzt. Die Inhalte fehlen jetzt nun mal und deswegen bist du vielleicht durchgefallen oder hast eine schlechte Note. Und das wäre doch blöd, weil du nutzt ja diese Chance, die du hast, selber nicht. Niemand sitzt neben dir und guckt dir über die Schulter, während du das Ding hier schreibst, die Doku. Das ist alles in deiner Hand. Du kannst dir das Thema ausdenken, du kannst die Struktur, die Inhalte, das kannst du alles völlig frei gestalten und hast dafür auch im Vergleich zu so einer schriftlichen Prüfung relativ viel Zeit. Also nutzt sie doch auch aus. Du hast alles in deiner Hand. Das heißt aber auch, wenn du durchfällst und eine schlechte Note kriegst, ist niemand anderes außer dir dafür verantwortlich. Und wenn du dein Potenzial, was du hast, in diesem Fall die Seiten, nicht ausnutzt, ja, dann bist du am Ende leider selber schuld, wenn du die Inhalte nicht lieferst, obwohl du sie hättest liefern können. Also, das nochmal die letzte Motivation. Wäre doch blöd, wenn du eine schlechte Note hast und fragst dich dann dein Leben lang, hat es daran gelegen, dass ich noch zwei Seiten hätte schreiben können? Vielleicht hätte das ja den Ausschlag gegeben für die bessere Note. Also, Fazit für heute. Nutze die Seitenzahl, die du ausnutzen darfst, voll aus.

[16:36] Überziehe nicht, aber nutze es so weit es eben geht aus, die Seitenzahlen für Fließtext und Anhang. Aber fülle das bitte nur mit sinnvollen Inhalten. Füll das nicht mit irgendwelchen inhaltsleeren generierten Kram oder irgendwelchen, habe ich auch schon zum Beispiel gesehen, Klassendiagrammen mit zwei Klassen drauf. Das ist jetzt nicht übertrieben. Die füllen dann eine ganze Seite mit zwei Klassen. Das ist ein bisschen wenig. Das ist ein bisschen inhaltsleer. Das ist auch nicht spannend oder interessant und zeigt auch nicht deine tolle Leistung nach drei Jahren Ausbildung, sondern das ist so, ich musste hier halt irgendwas malen, weil ich muss ja auf die Seitenzahl kommen. Bitte so nicht verstehen, das meine ich nicht. Füll die Dokumentation mit sinnvollen Inhalten, die ich als Prüfender auch bewerten kann, wo ich dir eine Note für geben kann. Die zeigt, dass du deinen Job beherrschst. Darum geht es in dieser Abschlussprüfung.

[17:20] Das war’s für heute. Ich wünsche dir viel Erfolg bei deiner Dokumentation und hoffe, dass du deine Seitenvorgabe auch einhältst und mit sinnvollen Inhalten füllst. Mach’s gut!

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.