IT-Berufe-Podcast, a podcast by Stefan Macke - Stats, Episodes and Rankings - My Podcast Data
Realistische Dauer der Projektdokumentation – IT-Berufe-Podcast-Shorts #15
Monday, July 6, 2026 • Duration 11:46
Um die realistische Dauer deiner IHK-Projektdokumentation geht es in der fünfzehnten Episode der Shorts des IT-Berufe-Podcasts.
Die wichtigste Aussage ist kurz: Plane für deine Projektdokumentation so viel Zeit ein, wie du bekommen kannst. Weil die Vorgaben der IHKen stark unterschiedlich sind und die Doku einen großen Einfluss auf deine Abschlussnote hat, lohnt es sich, deutlich mehr Zeit für Formulierung, Korrekturen, Feedback und saubere Aufbereitung einzuplanen. Die knappen "offiziellen" Zeitvorgaben für die umfangreiche Dokumentation sind unrealistisch, deshalb sollte die Doku in deiner Priorisierung weit oben stehen.
Inhalt
Wie viel Zeit du für die Projektdokumentation einplanen solltest
Die kurze Antwort lautet: so viel Zeit, wie deine IHK dir erlaubt. Praktisch heißt das aber: Plane eher mehr Zeit ein, als offiziell irgendwo steht, weil die Projektdokumentation ein zentrales Prüfungsartefakt ist und einen großen Anteil an deiner Abschlussnote hat.
Unterschiedliche Vorgaben der IHKen
Ein zentrales Problem ist, dass die IHKen in Deutschland nicht überall gleich vorgehen.
Manche IHKen erlauben, die Projektdokumentation innerhalb der offiziellen Projektzeit zu schreiben.
Andere IHKen erlauben das nicht oder machen andere Vorgaben.
Teilweise gibt es sogar feste Zeitanteile, zum Beispiel 15% der Projektzeit.
Bei 80 Stunden Projektzeit in der Anwendungsentwicklung wären das dann 12 Stunden für die Dokumentation.
Andere IHKen machen gar keine konkrete Zeitvorgabe, sodass du faktisch bis zur Abgabe daran arbeiten kannst.
Dadurch entstehen sehr unterschiedliche Voraussetzungen. Wenn eine Person nur 12 Stunden einplanen darf und eine andere faktisch deutlich mehr Zeit nutzen kann, wirkt sich das fast zwangsläufig auf die Qualität der Dokumentation aus.
Warum mehr Zeit sinnvoll ist
Die Projektdokumentation wird bewertet. Entscheidend ist am Ende nicht, ob du exakt eine vorgegebene Stundenzahl eingehalten hast, sondern wie gut das Ergebnis ist.
Deshalb sollte die Doku möglichst sauber und vollständig sein:
Fehler korrigieren
sauber formulieren
Referenzen prüfen
ein ordentliches Inhaltsverzeichnis erstellen
Bilder und Artefakte sinnvoll in Anhang oder Dokument einbauen
andere Personen Korrektur lesen lassen
Die Empfehlung ist deshalb klar: Nutze jede realistisch verfügbare Zeit, um die Dokumentation rund zu machen.
Offizielle Planung und praktische Realität
Wenn deine IHK eine feste Zeitvorgabe macht, sollte diese natürlich in Projektplanung, Antrag und Dokumentation auftauchen. Gleichzeitig ist die Empfehlung, in der Realität trotzdem alle sinnvollen Möglichkeiten zu nutzen, um die Doku zu verbessern.
Der Grund: Eine gute Note bekommst du nicht dafür, dass du nur wenig Zeit investiert hast, sondern dafür, dass die Dokumentation am Ende gut ist.
Warum knappe Zeitvorgaben unrealistisch sind
Gerade bei umfangreichen Dokumentationen mit zum Beispiel 40 oder 50 Seiten sind die sehr kleinen "offiziellen" Zeitvorgaben aus meiner Sicht unrealistisch.
Denn zur Arbeit an der Doku gehört mehr als nur Schreiben:
viele Seiten Text formulieren
Inhalte überarbeiten
Layout und Struktur sauber setzen
Anhänge, Bilder und weitere Artefakte einbauen
zusätzliche Materialien teilweise erst erstellen
Eine umfangreiche, sauber gesetzte PDF-Dokumentation in nur 12 Stunden zu erstellen, ist nicht realistisch!
Priorisierung: Doku vor Perfektion im Projekt
Die klare Empfehlung lautet, deine Zeit nach dem Einfluss auf die Note zu priorisieren.
Das bedeutet im Zweifel:
lieber etwas weniger programmieren, konfigurieren oder installieren
dafür mehr Zeit in die Projektdokumentation stecken
Begründung:
Die Doku hat einen sehr hohen Einfluss auf die Abschlussnote.
Das eigentliche Projekt kannst du in Präsentation und Doku ohnehin nur ausschnittweise zeigen.
Deshalb kann zusätzliche Zeit für Formulierung, Überarbeitung und Feinschliff bei der Doku mehr Wirkung auf die Bewertung haben als noch mehr Arbeit am eigentlichen Projekt.
Natürlich kann man diese Prüfungslogik kritisch sehen – und das tue ich selbst auch. Denn eine umfangreiche Dokumentation zeigt nicht automatisch, wie gut jemand beruflich handlungsfähig ist. Solange die Prüfungsstruktur aber so ist wie sie ist, sollte man als Prüfling das Beste daraus machen.
Zusätzlicher Zeitdruck in der Abschlussphase
Diese Empfehlung ist in der Praxis nicht immer leicht umzusetzen. Gegen Ende der Ausbildung kommen oft mehrere Belastungen zusammen:
laufende Arbeit im Ausbildungsunternehmen
teilweise keine vollständige Freistellung
in manchen Fällen Projektarbeit außerhalb der Arbeitszeit
Vorbereitung auf die AP2
Vorbereitung auf Projektpräsentation und Fachgespräch
Durchführung des eigentlichen Projekts
Schreiben der Dokumentation
Trotzdem bleibt die Doku aus Bewertungssicht ein Schwerpunkt, den du bei deiner Zeitplanung besonders beachten solltest.
Abgrenzung: Projektdokumentation ist nicht dasselbe wie Benutzer- oder Entwicklerdoku
Zum Schluss unterscheide bitte nochmal ganz klar zwischen den verschiedenen "Dokumentationen".
Projektdokumentation
Das ist das Prüfungsartefakt, um das es im gesamten Podcast geht.
Fachliche Dokumentation im Projekt
Dazu gehören zum Beispiel:
Benutzerhandbuch
Entwicklerdokumentation
Klassendiagramm
Administrationsdokumentation
Netzplan
Diese Unterlagen gehören ohnehin zum Projekt dazu und sind Pflichtbestandteile. Dafür gibt es bei vielen IHKen eigene Bewertungsanteile. Wenn solche Dokumentationen fehlen, kann sich das direkt negativ auf die Note auswirken.
Realistische Planung für diese fachlichen Doku-Anteile
Für diese projektbezogenen Dokumentationen sollte die Zeitplanung realistisch bleiben.
Ein sehr umfangreiches Handbuch mit unrealistisch wenig angesetzter Zeit passt nicht.
Kleinere Dokumentationsartefakte wie ein Netzplan oder ähnliche Unterlagen können dagegen mit wenigen Stunden realistisch geplant werden.
Fazit
Meine Kernaussage ist eindeutig: Investiere in die Projektdokumentation lieber mehr Zeit als zu wenig. Wegen der hohen Bedeutung für deine Note, der sehr unterschiedlichen IHK-Vorgaben und der unrealistischen offiziellen Zeitvorgaben lohnt es sich, genügend Zeit für Überarbeitung, Feedback und Feinschliff einzuplanen. Eine gute Dokumentation kann mehr Einfluss auf dein Ergebnis haben als zusätzliche Detailarbeit am eigentlichen Projekt.
Transkription der gesamten Episode
Automatisch erzeugte Transkription der Episode
[0:21] So, heute habe ich mal ein kleines Thema mitgebracht und ich glaube, heute wird es wirklich mal ein Short. Und die Frage, die ich heute behandeln möchte, ist, wie viel Zeit sollte ich für meine Projektdokumentation einplanen? Also du weißt schon, das Prüfungsartefakt, das, was du dem Prüfungsausschuss vorlegst, wo ein sehr, sehr großer Teil deiner Abschlussnote von abhängt. Ja, genau dieses Ding, was je nach IHK zwischen 20 und 60 Seiten lang sein kann oder vielleicht noch kleiner oder noch länger. Ich weiß das nicht von allen 79 IHK, aber sagen wir mal im Durchschnitt vielleicht 30, 40, 50 Seiten. Dieses Ding, was du dann wahrscheinlich über eine Online-Plattform einreichst oder ausgedruckt und gebunden und ja, auch das habe ich schon gehört, bei der IHK einreichst, damit das bewertet werden kann. Wie viel Zeit brauchst du dafür? Und das Too Long Didn’t Read, was ich immer Games by Einschieger mache, ist, ganz kurz gesagt, so viel wie deine IHK dir erlaubt. So, was soll das wieder heißen?
[1:18] Du weißt, 79 IHK gibt es in Deutschland. Jede macht wieder mal so ein bisschen ihr eigenes Ding, wenn sie möchte. Die meisten halten sich auch vielleicht eine einheitliche Vorgabe. Aber einige Sachen sind in den Berufsverordnungen der IT-Berufe halt nicht einheitlich geregelt. Zum Beispiel, ob die Projektdokumentationen überhaupt in deinen 80 oder 40 Stunden Projektzeit geschrieben werden dürfen. Einige IHK erlauben das, andere nicht. Und es kommt darauf an, wie man Gesetzestexte interpretiert und wer bei der IHK was entscheidet. Und ich weiß nicht, wovon es noch abhängt. Deswegen gibt es einfach ein Wir-Wahr an verschiedenen Lösungen und an verschiedenen Vorgaben und verschiedenen Wünschen, die IACAN so an diese Abschlussprojekte haben. Und da kann es dann durchaus sein, dass es da vielleicht auch harte Vorgaben gibt. Zum Beispiel innerhalb deiner Projektzeit ist das einzuplanen mit exakt 15 Prozent deiner Zeit. Und das wäre dann bei Anmerkungsentwicklung, wenn ich 80 Stunden habe, 12 Stunden der Projektzeit. Muss dann für die Projektdokumentationen. Eingesetzt werden. Andere IHK erlauben, dass man das einfach außerhalb der Projektzeit schreiben kann und geben gar keine Zeitvorgabe. Das heißt, da hast du quasi unendlich viel Zeit, also bis zur Abgabe der Doku natürlich, um deine Doku zu schreiben. Und da sieht man schon irgendwie, dass das ein bisschen unfair ist. Also wenn IHK einen Vorgaben machen, du darfst maximal zwölf Stunden dran sitzen und andere haben quasi unendlich viel Zeit.
[2:36] Wie unterschiedlich sehen diese Dokus dann wohl aus, wenn ich wirklich nur zwölf Stunden in dieses Dokument stecke? Das kann ich ja gar nicht. so gut formulieren, gestalten, die Referenzen prüfen und ich weiß nicht was alles, wie jemand, der unendlich Zeit dafür hat. Also, da sieht man schon irgendwie, dass das alleine schon unfair ist. Und deswegen muss ich ehrlich gesagt sagen, aus meiner Sicht als Prüfer empfehle ich das sogar, es ist ganz egal, was dein IHK dir für Vorgaben macht. Nutze einfach so viel Zeit, wie du kriegen kannst, und mach diese Dokumentation perfekt, in Anführungszeichen. Lass da jemanden Korrektur lesen, im besten Fall jemanden, der sich auskennt, Ausbilder, Ausbilderin vielleicht.
[3:15] Korrigiere alle Fehler, die dir auffallen, mach die Referenzen sauber, mach ein vernünftiges Inhaltsbezeichnis, pack alle Bilder in den Anhang etc. Mach das Ding rund. Das ist dein Prüfungsartefakt. Das Ding wird bewertet. Und am Ende wirst du nicht eine Eins dafür kriegen, weil du exakt zwölf Stunden daran gearbeitet hast, aber das Ding sieht aus wie Grütze, sondern die Leute werden dieses Ding nehmen, was aussieht wie Grütze und werden das bewerten. Und dann guckt auch keiner mehr danach, ob du zehn oder zwölf oder dreihundert Stunden dran gesessen hast, wenn es Mist ist. Das heißt, um allein diesen Nachteil auszugleichen, dass andere IHK den Prüfling quasi unendlich viel Zeit geben für die Bearbeitung, würde ich sagen, das ist schön, dass du da solche Vorgaben hast, das schreibst du dann auch schön in deine Projektplanung rein, in den Antrag und in der Doku wiederholst du es nochmal, aber in der Realität nutzt du bitte sämtliche Zeit, die du hast, um diese Doku rund zu machen. Alles andere wäre dumm.
[4:08] So, das ist meine persönliche Empfehlung. Deswegen sage ich, du hast so viel Zeit, wie deine IHK dir erlaubt, aber rechne mit deutlich mehr Zeit. Am Ende ist dieses eine Prüfungsartefakt, die Projektdokumentation, das Ding, was am meisten Anteil an deiner Abschlussnote hat. Also wäre es doch blöd, da so wenig Zeit wie möglich zu investieren. Ich würde stattdessen einfach so viel Zeit wie möglich investieren. Und ich würde sogar sagen, im Zweifel programmierst du ein bisschen weniger oder konfigurierst ein bisschen weniger oder installierst ein bisschen weniger und schreibst mehr an der Dokumente, weil das ist das Ding, was bewertet wird. Ist das gut, dass man IT-Berufe so bewertet? Darüber kann man streiten. Ich finde, das ist auch nicht die beste Wahl, um.
[4:51] Herauszufinden, ob jemand seinen Beruf beherrscht, dass man ein 40-seitiges Dokument darüber schreibt, vor allem mit Hilfe von KI zum Beispiel heute oder früher auch schon, gab es immer schon Ausbilder, die drüber geguckt haben und das korrigiert haben. Also wie viel Aussagekraft hat dieses Dokument da noch? Da kann man jetzt wirklich sehr schön drüber streiten und dann auch Vorschläge machen, dass das in Zukunft vielleicht anders ist. Aber solange das nicht passiert ist und wir diese Prüfungsordnung und Struktur noch so haben, würde ich sagen, halt dich dran und hol das Beste für dich raus. Ich sage es immer wieder, die Doku, das ist das Ding, was du in deiner Hand hast, aus meiner Vorgabe jetzt hier, nimm dir so viel Zeit, wie du brauchst. Du kannst das tausendmal Korrektur lesen, du kannst es eine Woche liegen lassen vor der Abgabe und dann nochmal drauf gucken. Du kannst jemand anderen drüber lesen lassen, Du kannst ganz viel Zeit investieren, bis das Ding halt vernünftig und rund ist. Und die würde ich auf jeden Fall auch investieren.
[5:42] Und ganz ehrlich, wenn jemand bei einer IHK sagt, ich erwarte von dir ein 50-seitiges, perfekt gesetztes PDF-Dokument innerhalb von maximal zwölf Stunden, da sind wir uns, glaube ich, alle einig, dass das absolut utopisch ist. Das wird niemand hinbekommen. Auch wenn du dein Projekt perfekt umgesetzt hast, allein die Formulierung von so vielen Seiten Text dauert definitiv länger als zwölf Stunden. Dann kommt noch hinzu, du musst vernünftig setzen, du musst die ganzen Artefakte, Anhänge, Bilder etc. da reinbauen. Die musst du teilweise für die Doku ja sogar noch anfertigen extra. Also das ist alles völlig unrealistisch. Da sind wir uns hoffentlich alle einig. Und wenn dann tatsächlich jemand kommt und sagt, Moment, wir wollten von dir 50 Seiten haben und du hast uns tatsächlich 50 Seiten geliefert, obwohl du nur 12 Stunden Zeit hattest, wie ist das denn überhaupt möglich?
[6:28] Dann tut mir leid, schneiden die Leute sich ins eigene Fleisch. Also da wird keiner nachfragen. Es wissen alle, die an dieser Prüfung beteiligt sind, dass diese Vorgaben absoluter Bullshit sind. Und deswegen geh davon aus, dass du die Zeit investieren kannst. Die Leute werden dich nicht danach fragen, wie lange du da dran gesessen hast, sondern werden das einigermaßen realistisch auch in der Zeitplanung, wenn es denn Vorgabe ist, der IHK berücksichtigt ist, dann wird da kein Mensch nachfragen, weil sowieso alle wissen, dass das alles ausgedachte Zahlen sind und deswegen nimm dir die Zeit, lass das Ding Korrektur lesen, mach das Ding rund und gib es dann ab und dann hast du alles getan, was du tun kannst, damit du da auch eine gute Note bekommst. Also, nimm dir so viel Zeit, wie du kriegen kannst, ganz blöd gesagt. Das hört sich jetzt so einfach an. Ich weiß, einige Prüflinge müssen neben dieser Projektarbeit auch noch richtig arbeiten. Das heißt, da ist das Ausbildungsunternehmen hinterher, dass man auch ein bisschen Geld verdient für das Unternehmen. Da wird man nicht freigestellt. Ich habe sogar schon von Unternehmen gehört, da muss man die Projektarbeit außerhalb der Arbeitszeit machen. Also gut, das ist jetzt heute hier nicht das Thema. Auf jeden Fall kann es ja sein, dass du in deinem Projektzeitraum noch ein bisschen Stress hast. Ach ja, da steht ja noch so eine AP2 an, für die du lernen musst. Projektpräsentation, Fachgespräch muss vorbereitet werden und dann auch noch tatsächlich eine Software entwickeln oder Netzwerk planen oder was auch immer du so machst und dann auch noch diese Doku schreiben. Also gegen Ende der Ausbildung wird es ein bisschen knapp zeitlich auch manchmal.
[7:46] Von daher wird es manchmal auch schwierig, sich die Zeit damit zu nehmen. Aber halt dir nochmal vor Augen, die Doku ist das eine Prüfungsartefakt mit dem höchsten Impact auf deine Note. Der größte Teil der Note, der geht von der Doku aus. Und demnach würde ich meine Zeiten auch priorisieren. Steck da die Zeit rein, das ist am Ende, ja, wie gesagt, hat mehr Impact, wirkt sich mehr auf deine Note aus, als die Software rund zu programmieren. Weil die kannst du in deiner kurzen Präsion und einer kurzen Doku sowieso nicht komplett zeigen. Also würde ich tatsächlich lieber ein bisschen mehr Text schreiben und ein bisschen den Text umformulieren, schöner machen, etc..
[8:24] Als die Zeit in das echte Projekt zu stecken. Wie gesagt, ich persönlich finde diese Empfehlung bescheuert, weil ich natürlich eigentlich will, dass die Leute beruflich handlungsfähig werden, weil das ist der Auftrag der beruflichen Ausbildung. Und nicht, dass man schön PDF-Dateien schreiben kann. Aber wie gesagt, solange die Prüfungsstruktur so ist, würde ich empfehlen, wenn du das Beste rausholen willst, investiere die Zeit in die Doku. Übrigens, kurze Abgrenzung zum Schluss, eine Benutzer-Dokumentation, Entwickler-Dokumentation, Admin-Dokumentation, was auch immer, gehört natürlich sowieso zum Projekt dazu. Also ein Handbuch für die Benutzer oder ein Klassendiagramm für die Entwickler oder ein Netzplan für die Physikollegen. Das ist sowieso Teil der Projektarbeit, das musst du eh immer machen. Das ist bei unserer IHK zum Beispiel, allein dafür kriegt man 15% der Note. Das heißt, wenn du ein Projekt abgibst, wo keine Dokumentation drin ist und nicht die Projektdokumentation, die hier gemein ist, sondern das, was ich eben aufgezählt habe, dann kannst du schon keine, was ist es, 15%, 85%, kriegst du noch eine 2, aber du kannst schon keine 1 mehr bekommen, wenn du keine Dokumentation drin hast. Also die gehört immer da rein. Dafür gibt es auch keine Ausnahme. Das ist Pflichtprogramm quasi, ein Pflichtartefakt aus meiner Sicht in jeder Projektarbeit.
[9:32] Und da muss es natürlich einigermaßen realistisch sein. Also du kannst nicht noch ein 70-seitiges Benutzerhandbuch zu deinem Projekt erstellen und dann in die Projektplanung schreiben, dafür habe ich vier Stunden gebraucht. Also das ist natürlich, das passt überhaupt nicht. Ja, so, also das muss einigermaßen realistisch sein, aber sind wir mal ganz ehrlich, ich habe jetzt irgendwie, ich habe zwei Wochen was programmiert oder ich habe eine Woche lang irgendwie was auch immer Netzwerk geplant oder so, da werde ich dann jetzt nicht noch 20 Stunden brauchen, um da jetzt einen Netzwerkplan für zu zeichnen. Also da sind wir dann mit wenigen Stunden dabei, zwei, drei Stunden oder sowas für die Doku, dann passt das.
[10:03] Aber die Projektdokumentation mit all die Artefakten etc., das ist ja wirklich ein, für viele Azubis tatsächlich, die größte Arbeit, die sie bis dahin geschrieben haben. Es gibt ja auch viele Azubis, die zum Beispiel kein Abi gemacht haben, keine Facharbeit oder sonst irgendwas geschrieben haben. Und das schreibt man nicht mal eben runter. So ein 50 Seiten Ding. Ja, also das ist völlig utopisch. Deswegen plan da vernünftig Zeit ein, plan auch Feedback schleifen ein, lass da jemanden rübergucken. Ich sag’s jetzt zum dritten Mal, deswegen würde ich sagen, wir hören das mal auf, weil ich fang mir an zu wiederholen. Also nimm dir so viel Zeit, wie die IHK erlaubt, aber mach lieber doch mehr, weil dieses eine Prüfungsartefakt ist so wichtig für deine Note. Es wäre dumm, wenn du die Zeit nicht investierst.
[10:43] So, das war’s für heute. Bis zum nächsten Mal.
Einhaltung der Projektbearbeitungszeit (40 bzw. 80 Stunden) – IT-Berufe-Podcast-Shorts #14
Monday, June 29, 2026 • Duration 14:17
Um die exakte Einhaltung der Projektbearbeitungszeit (40 bzw. 80 Stunden) beim Abschlussprojekt geht es in der vierzehnten Episode der Shorts des IT-Berufe-Podcasts.
Für die betriebliche Projektarbeit solltest du die vorgegebene Zeit von 40 Stunden bzw. 80 Stunden in der Anwendungsentwicklung praktisch exakt einhalten. Mehr Zeit kann zum Nichtbestehen führen, weniger Zeit ist zwar rechtlich grundsätzlich möglich, verschlechtert aber unnötig deine Prüfungsleistung. Wenn deine Planung oder die IHK-Vorgaben unklar sind, solltest du das vor dem Projektantrag klären und dein Projekt so darstellen, dass du am Ende genau auf die erlaubte Stundenzahl kommst.
Inhalt
Kernaussage
Für die betriebliche Projektarbeit gelten feste Zeitvorgaben: 40 Stunden in den meisten IT-Berufen und 80 Stunden in der Fachrichtung Anwendungsentwicklung. Diese Zeit solltest du im Projektantrag und in der Projektdurchführung möglichst exakt einhalten.
Zeitvorgaben: mehr geht nicht
Die rechtliche Grundlage – die Berufsverordnung – nennt für die betriebliche Projektarbeit eine Prüfungszeit von höchstens 80 Stunden. Daraus folgt:
Weniger Zeit ist rechtlich grundsätzlich erlaubt.
Mehr Zeit ist nicht erlaubt.
Wenn du die erlaubte Zeit überschreitest, hältst du die Prüfungsvorgaben nicht ein und könntest dadurch durch die Prüfung fallen.
Deshalb sollte in deiner Zeitplanung am Ende genau die erlaubte Stundenzahl stehen:
40 Stunden in den meisten IT-Berufen
80 Stunden in der Anwendungsentwicklung
Warum die exakte Planung erwartet wird
Projektplanung gehört zu den Ausbildungsinhalten in allen IT-Berufen. Dazu gehört auch, zeitliche Vorgaben einzuhalten. Auch wenn eine Planung auf die Stunde genau in der Realität oft unrealistisch ist, wird in der Prüfung erwartet, dass du dich an die formalen Vorgaben hältst.
Weniger Zeit ist zwar erlaubt, aber unklug
Pufferzeit im Projektantrag
Warum ein abgelehnter Antrag problematisch ist
Abweichungen vom Projektantrag helfen bei Überziehung nicht
Umgang mit Abweichungen während des Projekts
Fazit
Links
Transkription der gesamten Episode
Automatisch erzeugte Transkription der Episode
Ist die Projektdokumentation Teil der Bearbeitungszeit des IHK-Abschlussprojekts (40h bzw. 80h)? – IT-Berufe-Podcast-Shorts #13
Monday, June 22, 2026 • Duration 15:19
Um das Einplanen der Projektdokumentation als Teil der Bearbeitungszeit des IHK-Abschlussprojekts (40h bzw. 80h) geht es in der dreizehnten Episode der Shorts des IT-Berufe-Podcasts.
Bei der Frage, ob die Zeit für die Projektdokumentation in die 40 bzw. 80 Stunden der Projektarbeit gehört, gibt es keine einheitliche Regelung, sondern es hängt von deiner IHK ab. Viele IHKen und auch der DIHK verlangen, dass diese Zeit mit eingeplant wird, auch wenn das in der Praxis oft als unrealistisch gesehen wird. Ich würde dir deshalb empfehlen, die Vorgaben deiner konkreten IHK zu prüfen und im Zweifel die Doku-Zeit vorsichtshalber in die Planung aufzunehmen.
Inhalt
Ob die Zeit für die Projektdokumentation zur offiziellen Projektzeit zählt, ist je nach IHK unterschiedlich geregelt. Eine einheitliche bundesweite Regelung gibt es dazu nicht, obwohl sich viele Prüflinge genau diese Klarheit wünschen. Nach der Recherche im Podcast erwarten die meisten IHKen, dass die Dokumentation innerhalb der vorgegebenen 40 oder 80 Stunden entsteht. Gleichzeitig wird das als praxisfern bewertet, weil die Projektzeit ohnehin oft knapp ist und umfangreiche Dokumentationen zusätzlich kaum realistisch in wenigen Stunden erstellt werden können.
Worum es bei der Frage geht
Gemeint ist die Zeit für die finale Projektdokumentation für den Prüfungsausschuss, also das ausformulierte Dokument mit Inhalt, Struktur, Formatierung, Bildern und Anhängen. Die zentrale Frage ist, ob diese Zeit offiziell Teil der Projektbearbeitungszeit ist oder außerhalb davon läuft.
Warum es dazu unterschiedliche Auffassungen gibt
In den Berufsverordnungen steht, dass der/die Prüfling eine betriebliche Projektarbeit durchführen und mit praxisbezogenen Unterlagen dokumentieren muss. Außerdem wird dort genannt, dass die Prüfungszeit für Projektarbeit und Dokumentation höchstens 80 Stunden beträgt, bezogen auf die Fachinformatiker:innen Anwendungsentwicklung.
FIAusbV §12 (2)
Der Prüfling hat eine betriebliche Projektarbeit durchzuführen und mit praxisbezogenen Unterlagen zu dokumentieren.
Einschätzung zur Praxis
Rolle von IHK und DIHK
Was du für deine Planung mitnehmen kannst
Praktische Empfehlung
Fazit
Links
Transkription der gesamten Episode
Automatisch erzeugte Transkription der Episode
Um die mündliche Ergänzungsprüfung (MEP) inkl. Erklärung, Benotung, Inhalte und Vorbereitung geht es in der einhundertsiebenundneunzigsten Episode des IT-Berufe-Podcasts.
Die mündliche Ergänzungsprüfung (MEP) ist die letzte Möglichkeit, wenn du in einer schriftlichen Prüfung aus Teil 2 der Abschlussprüfung durchgefallen bist und dadurch das Bestehen noch retten kannst. Sie ist nur für einen einzigen schriftlichen Prüfungsbereich in AP2 möglich, dauert etwa 15 Minuten und wird im Verhältnis 2:1 mit dem bisherigen Ergebnis verrechnet, weshalb sie eine schlechte Note nur begrenzt ausgleichen kann. Wichtig ist vor allem: Kläre Ablauf, Antrag und Termin direkt mit deiner IHK und bereite dich inhaltlich wie auf die betroffene schriftliche Prüfung vor, aber mit Fokus auf mündliches Erklären.
Inhalt
Mündliche Ergänzungsprüfung in den IT-Berufen
Ich fasse hier die Regeln zur mündlichen Ergänzungsprüfung (MEP) nach der seit 2020 geltenden Berufsverordnung zusammen. Die MEP betrifft nur Prüflinge, die in einem schriftlichen Prüfungsbereich von Teil 2 der Abschlussprüfung durchgefallen sind und die Prüfung dadurch eventuell noch bestehen können.
Wofür die MEP gedacht ist
Die MEP ist dafür da, eine nicht bestandene schriftliche Prüfung in Teil 2 auszugleichen. Sie ist nicht dafür da, einfach eine Note zu verbessern.
Wichtig dabei:
AP1 kann nicht durch eine MEP ausgeglichen werden.
Auch das Projekt in AP2 kann nicht durch eine MEP ausgeglichen werden.
Die MEP ist nur für die drei schriftlichen Prüfungsbereiche von AP2 möglich:
die zwei berufsspezifischen schriftlichen Prüfungen
Wann du in eine MEP musst
Wer die MEP beantragen muss
In welchen Prüfungsbereichen die MEP möglich ist
Wie die MEP bewertet wird
Was diese Gewichtung praktisch bedeutet
Wie der Ablauf organisiert ist
Welche Inhalte in der MEP drankommen können
Wie du dich vorbereiten kannst
Einschätzung zur MEP
Wichtigstes Fazit
Links
Transkription der gesamten Episode
Automatisch erzeugte Transkription der Episode
Umgang mit Fehlern in der Projektdokumentation in der Projektpräsentation – IT-Berufe-Podcast-Shorts #12
Monday, May 11, 2026 • Duration 12:54
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
Welche Fehler du korrigieren und ggf. ansprechen solltest
Professioneller Umgang mit Fehlern
Was in die Präsentation gehört
Kleine Auswirkungen
Größere Auswirkungen
Was du nicht tun solltest
Vorbereitung auf das Fachgespräch
Besonderheit beim Prüfungsausschuss
Einfluss auf die Note
Zentrale Kernaussage
Vorbeugung vor der Abgabe
Links
Transkription der gesamten Episode
Automatisch erzeugte Transkription der Episode
Sinnvolle Prüfungsvorbereitung mit alten IHK-Prüfungen – IT-Berufe-Podcast-Shorts #11
Monday, May 4, 2026 • Duration 07:01
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
Wie alte und neue Prüfungsteile zusammenhängen
Warum du immer den aktuellen Prüfungskatalog brauchst
So gehst du bei alten Prüfungen sinnvoll vor
Lass dich von alten Aufgaben nicht verunsichern
Lösungen nie nur stumpf vergleichen
Feedback ist ein wichtiger Teil der Vorbereitung
Fazit
Links
Transkription der gesamten Episode
Automatisch erzeugte Transkription der Episode
Platzierung von Artefakten in der Projektdokumentation – IT-Berufe-Podcast-Shorts #10
Monday, April 27, 2026 • Duration 17:41
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.
Seitenzahl ist nicht das eigentliche Problem
Ausnahme: Lesbarkeit
Artefakte nicht als Seitenfüller verwenden
Artefakte haben einen Zweck
Was in den Fließtext gehört
Fazit
Links
Transkription der gesamten Episode
Automatisch erzeugte Transkription der Episode
Sinnvolle Anzahl der Seiten der Projektdokumentation – IT-Berufe-Podcast-Shorts #9
Monday, April 20, 2026 • Duration 18:32
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:
Zu viele Seiten können zu Abzügen führen
Zu wenige Seiten sind nicht direkt das Problem
Mein praktischer Rat: Nutze den verfügbaren Platz aus
Wie ich auf Seitenzahl und Inhalt schaue
Was du in eine Projektdokumentation aufnehmen könntest
Anforderungen
Architektur und technische Modelle
Infrastruktur und Systemdarstellung
Datenmodellierung und Schnittstellen
Prozesse und Abläufe
Umsetzungsnachweise
Projektorganisation
Planung und Wirtschaftlichkeit
Meine abschließende Motivation für dich
Links
Transkription der gesamten Episode
Automatisch erzeugte Transkription der Episode
Stakeholder für deine IHK-Projektarbeit – IT-Berufe-Podcast-Shorts #8
Monday, April 13, 2026 • Duration 23:49
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:
Mögliche Stakeholder und ihre typischen Anforderungen
Kund:innen oder Auftraggeber:innen
Endbenutzer:innen
Projektleitung
Entwickler:innen beziehungsweise Administrator:innen
IT-Betrieb und Support
Datenschutz und Compliance
Staat und Gesetzgeber
Sicherheitsverantwortliche
Kulturkreis
Management oder Geschäftsführung
Externe Dienstleistende
Hardware beziehungsweise vorhandene Infrastruktur
So kannst du in deinem Projekt vorgehen
Beispiel aus einem kleinen Web-App-Projekt
Fazit
Links
Transkription der gesamten Episode
Automatisch erzeugte Transkription der Episode
Eh-Da-Kosten und laufende Kosten bei der Projektarbeit – IT-Berufe-Podcast-Shorts #7
Monday, April 6, 2026 • Duration 17:13
Um „Eh-Da-Kosten“ und laufende Kosten bei der Projektarbeit geht es in der siebten Episode der Shorts des IT-Berufe-Podcasts.
Ich zeige dir, dass du in der Kostenbetrachtung deines Abschlussprojekts nicht nur neu angeschaffte Dinge einplanen solltest, sondern auch vorhandene Ressourcen wie Arbeitszeit, Server, VMs oder Lizenzen. Solche „EDA-Kosten“ sind nicht kostenlos, weil sie Ressourcen binden und damit Opportunitätskosten verursachen. Außerdem solltest du laufende Kosten wie Betrieb, Wartung, Strom, Lizenzen oder Support immer mit berücksichtigen und dir dafür möglichst Pauschalen oder Stundensätze aus deinem Unternehmen geben lassen.
Inhalt
Worum es mir geht
Ich zeige dir, dass in Projektdokumentationen und Präsentationen oft wichtige Kosten vergessen werden. Dadurch wirkt ein Abschlussprojekt schnell zu günstig oder amortisiert sich unrealistisch schnell. Für eine realistische Kostenbetrachtung solltest du nicht nur neu angeschaffte Dinge berücksichtigen, sondern alle Kosten, die durch dein Projekt entstehen.
Vorhandene Ressourcen sind nicht kostenlos
Ein häufiger Fehler ist die Annahme, dass vorhandene Ressourcen nichts kosten, nur weil sie schon im Unternehmen da sind. Genau darum geht es bei den sogenannten "EDA-Kosten":
der Server ist schon da
die Lizenz ist schon bezahlt
der/die Kolleg:in ist sowieso im Unternehmen
du erhältst ohnehin deine Ausbildungsvergütung
Ich mache klar: Das ist keine sinnvolle Rechnung. Alles, was du für dein Projekt nutzt, kostet Geld und muss letztlich von Kund:innen mitfinanziert werden.
Opportunitätskosten
Ein wichtiger Gedanke dabei sind die Opportunitätskosten, also die Kosten der entgangenen Gelegenheit.
Beispiele:
Wenn ein:e Softwareentwickler:in zwei Stunden deinen Code reviewt, kann diese Person in der Zeit nichts anderes für das Unternehmen leisten.
Wenn dein Projekt auf einem vorhandenen Server läuft, stehen CPU, RAM, Storage oder Netzwerkkapazität nicht mehr vollständig für andere Anwendungen zur Verfügung.
Kosten fair und anteilig umlegen
Kosten nicht selbst im Detail berechnen
Laufende Kosten nicht vergessen
Warum das für die Amortisation wichtig ist
Beispiele für mögliche Kosten
Für Systemintegration
Für Anwendungsentwicklung
Meine Empfehlung für deine Projektdokumentation
Fazit
Links
Transkription der gesamten Episode
Automatisch erzeugte Transkription der Episode
Apple Podcasts
Spotify
🇩🇪 Germany - technology
06/05/2026
#49
→
🇩🇪 Germany - technology
05/05/2026
#49
↘
🇩🇪 Germany - technology
04/05/2026
Dazu kommt:
Prüfungsleistungen sollen vergleichbar sein.
Ohne feste Obergrenze könnten einzelne Prüflinge deutlich mehr Zeit investieren als andere.
Größere Projekte würden auch zu umfangreicheren Dokumentationen führen, die von Prüfenden gelesen werden müssten.
Auch wenn das Gesetz "höchstens" sagt, ist weniger Zeit aus Sicht der Prüfungsleistung keine gute Idee. Wenn du freiwillig weniger Zeit nutzt,
zeigst du weniger von deinen Fähigkeiten,
nutzt deinen möglichen Bewertungsrahmen nicht aus,
und stellst dich schlechter dar als jemand, der die volle Zeit sinnvoll ausschöpft.
Die Aussage dazu ist klar: Weniger Zeit zu planen oder zu nutzen ist möglich, aber für deine Note eher nachteilig.
Manche planen im Antrag bewusst Pufferzeit ein, weil Projekte nie perfekt planbar sind. Dabei gilt aber:
Ob das erlaubt oder sogar gewünscht ist, hängt von der IHK ab.
Es gibt IHKs, die einen Puffer akzeptieren oder fordern.
Es gibt auch Fälle, in denen ein Antrag mit eingeplanter Pufferzeit abgelehnt würde.
Die Empfehlung ist deshalb:
Informiere dich vorher bei deiner IHK, welche Erwartungen gelten.
Reiche den Antrag möglichst direkt passend ein, damit er nicht wegen solcher Punkte zurückkommt.
Wenn dein Projektantrag abgelehnt wird und du ihn überarbeiten musst,
verlierst du Zeit durch Überarbeitung und erneute Prüfung,
darfst du mit dem Projekt erst nach Genehmigung anfangen,
und bekommst dadurch zusätzlichen Zeitdruck.
Deshalb ist es sinnvoll, die formalen Anforderungen vorab zu klären.
Auch wenn es in Projektdokumentationen oft ein Kapitel zu Abweichungen vom Projektantrag gibt, kannst du damit keine längere Projektzeit rechtfertigen. Wenn dein Projekt mit 80 oder 40 Stunden genehmigt wurde, bleibt diese Vorgabe bestehen.
Das heißt:
Eine Überschreitung lässt sich nicht einfach dadurch retten, dass du sie in der Doku erwähnst.
Der Prüfungsausschuss kann das als Verstoß gegen die Vorgaben werten.
Wenn du in einer Projektphase mehr Zeit brauchst als geplant, solltest du in der Darstellung dafür sorgen, dass du diese Zeit in einer anderen Phase wieder einsparst, damit du am Ende insgesamt auf die erlaubte Stundenzahl kommst.
Typisch ist dann ein Soll-Ist-Vergleich, in dem beschrieben wird, dass an einer Stelle mehr Zeit nötig war und an anderer Stelle entsprechend weniger. Auch wenn das in der Realität oft konstruiert wirkt, ist genau das Teil des Prüfungssystems.
Die Antwort auf die Ausgangsfrage ist eindeutig:
Mehr als die erlaubten 40 bzw. 80 Stunden solltest du nicht haben.
Weniger wäre zwar grundsätzlich möglich, ist für deine Prüfungsleistung aber nicht sinnvoll.
Plane dein Projekt so, dass du am Ende genau auf die vorgegebene Stundenzahl kommst.
Wenn es Unklarheiten zu Pufferzeiten oder Formvorgaben gibt, kläre das vorher mit deiner IHK.
[0:21] Heute habe ich mal ein Thema mitgebracht, woran ich immer denken muss, wenn ich mir wieder Projektanträge für die betriebliche Projektarbeit anschaue. Und zwar, muss ich eigentlich die vorgegebene Zeit für mein Projekt, nämlich 40 Stunden bei allen IT-Berufen und 80 Stunden bei der kleinen Ausnahme für AmnungsentwicklerInnen, muss ich diese Zeit eigentlich einhalten oder darf ich auch mehr oder weniger Zeit für mein Projekt haben?
[0:46] Und kurz vorweg gesagt, nein, du darfst nicht mehr oder weniger haben. Du solltest ziemlich genau exakt auf diese Zahl kommen. Etwas aufgeweicht, ja, du darfst auch weniger Zeit aufwenden, aber das wäre dumm, aber da kommen wir gleich drauf. Aber wenn du überziehst, hast du ein Problem, damit kannst du durch die Prüfung fallen. Das heißt, das solltest du auf keinen Fall machen. Deswegen nehmen wir erst mal das Daumenregel mit. In deiner Zeitplanung sollten unten exakt 40 Stunden für alle IT-Berufe außer Anbietungsentwicklung bzw. 80 Stunden für die Anbietungsentwicklung stehen. Alles andere ist nicht so sinnvoll. Und da gucken wir jetzt mal drauf, warum das so ist. Also Nummer 1, Abweichungen nach unten sind grundsätzlich okay, aber dumm. Aber wir gucken mal warum. Und zwar schauen wir als allererstes mal auf die gesetzliche Grundlage, die Berufsverordnung. Und da weißt du vielleicht, wir haben sieben verschiedene IT-Berufe, die alle einzelne Berufsverordnungen teilweise haben, beziehungsweise der Fachnummer hat gerade eine mit vier Unterpunkten für die einzelnen Fachrichtungen und so weiter. Aber du kannst dir die alle online angucken. Besetztes Texte sind frei verfügbar. Und ich nehme jetzt einfach mal den Paragraf 12, der FIE aus BF, also der Berufsverordnung für die Fachinformatiker. Und den findest du ziemlich genau, exakt so formuliert auch in allen anderen IT-Berufsverordnungen.
[2:01] Und da steht in Paragraf 12, Absatz 2, die Prüfungszeit beträgt für die betriebliche Projektarbeit und für die Dokumentation mit praxisbezogenen Unterlagenlagen, höchstens 80 Stunden. Die Prüfungszeit beträgt höchstens 80 Stunden. Kurz zusammengefasst. So, höchstens steht da. Da steht nicht, du musst exakt auf 80 Stunden kommen, was ja sowieso völlig unrealistisch ist. Kein Mensch kann ein Projekt so gut planen, dass er exakt genau 80 Stunden braucht. Sind wir uns alle einig, dass das sowieso Quatsch ist, glaube ich. Aber höchstens heißt, ich darf auch weniger. So steht es erstmal im Gesetz. Das heißt aber, höchstens heißt inklusive 80, aber darüber ist es vorbei. Das heißt, mehr ist nicht. Wenn du also länger gebraucht hast, dann hast du dich nicht an diese Vorgaben zur Prüfung gehalten und dann könntest du deswegen durch die Prüfung fallen.
[2:50] So wie mein Beispiel in meinem Prüfungskurs war, dein Chef gibt dir 100 Euro mit, um Brötchen zu kaufen und dann kommst du wieder und sagst, ja Chef, ich habe 110 ausgegeben. Ja, das ist schön, aber das war nicht dein Budget. Und was ist dann das Endergebnis? Du musst die 10 Euro auf deine eigenen Tasche zahlen, außer du hast einen vernünftigen Chef, der gibt dir das Geld dann wieder, weil dafür hast du leckere Brötchen geholt. Aber so mal als Beispiel, wenn du ein Budget hast, was du einhalten musst, dann kannst du auch nicht sagen, ja, sorry, ich habe es doppelt so viel ausgegeben. So, das geht nicht, kann man nicht machen. Und hier ist es auch so, wenn es exakte Vorgabe ist, halte ich an 80 Stunden, mehr geht nicht und du machst mehr. Ja, dann kann man dich deswegen durch die Prüfung fallen lassen, weil du einfach nicht an diese Vorgaben dich gehalten hast. Das ist nicht gut. So, vor allem gehört Projektplanung in allen IT-Berufen zu den Ausbildungsinhalten. Da steht ein Ausbildungsrahmenplan drin, Projektplanung, das gehört auf jeden Fall dazu, das muss man lernen in jedem IT-Beruf. Und früher war das sogar explizit in der Verordnung genannt unter dem Punkt zeitliche Vorgaben einhalten. Dieser Begriff, zeitliche Vorgaben ein, stand explizit in der Berufsordnung in allen IT-Berufen, was man da vermitteln musste. Heute ist es ein bisschen aufgeweicht und so ein bisschen schwammig, Projektplanung und so weiter. Aber gehört dazu. Ich kann, wenn ich Software-Entwicklungsprojekte zum Beispiel plane, auch nicht sagen, ich brauche irgendwas zwischen 100 und 1000 Personentagen.
[4:06] Die wollen das schon ein bisschen genauer wissen, die Leute, die das Geld dafür bezahlen. Und deswegen gehört das zum Ausführungsinhalt dazu. Und da kann ich auch nicht mal mein Abschlussprojekt sagen, irgendwas zwischen 10 und 100 Stunden. Das geht nicht. Man muss es schon vernünftig planen. So, wir sind uns alle einig, dass diese Planung sowieso utopisch, unrealistisch und meistens komplett überzogen wird in der Realität.
[4:28] Aber das heißt nicht, dass du das in deiner Doku auch so schreiben musst unter deinem Projektantrag, sondern da erwarten halt alle formale Vorgabe 80 Stunden. Also halt dich dran und mach nicht mehr.
[4:39] Also, machst du zu viel, kannst du durchfallen. Wenn du Glück hast und du hast die Planung schon im Projektantrag überzogen, dann wird man einfach deinen Projektantrag ablehnen und sagen, hier anpassen, maximal 80 Stunden, maximal 40 Stunden, was auch immer. Dann ist es gut. Aber angenommen, wir würden das erlauben, dass du mehr machen darfst, da könnte ja jeder Prüfling jetzt einfach lustig überziehen, wie er oder sie halt Bock hat. Und was haben wir dann für Projekte? Die dauern auf einmal 100 Stunden. Ja, okay, 200 Stunden. Ist das noch okay? 300 Stunden? Also wie lange wollen wir den Prüflingen denn erlauben, ihr Projekt zu machen? Und am Ende ist es dann ja auch nicht mehr vergleichbar. Einer, der 300 Stunden investiert hat und jemand, der 40 investiert hat, da muss ja was ganz anderes rauskommen von der Qualität her. Also man muss es irgendwie vereinheitlichen. Außerdem, das Projekt muss ja auch von Prüfenden, wie zum Beispiel mir, gelesen werden, die Dokumentation. Und wenn wir ein 300-Stunden-Projekt dokumentiert haben mit, wie viele Seiten sollen denn da rauskommen? 100 Seiten? Wer soll denn sowas lesen in seiner Freizeit? Das ist ja alles Ehrenamtlich, das Prüferamt. Das heißt, das funktioniert nicht, deswegen müssen wir immer eine Grenze setzen und die ist halt laut Gesetz bei 40 Stunden bis 80 Stunden gesetzt, also halt dich dran. Nach oben hin. So, jetzt steht aber ja höchstens im Gesetz, du darfst also weniger Stunden investieren, aber da frage ich jetzt einfach mal, warum willst du das machen? Warum solltest du das machen? Klar, du kannst sagen, ja, ich habe einfach keinen Bock zu arbeiten, ich mache einfach weniger. Ja, okay, Aber hier geht es ja um deine Prüfungsleiste und dafür kriegst du ja eine Note.
[6:03] Und wenn du jetzt freiwillig auf Zeit verzichtest, die du investieren könntest, um eine bessere Note zu bekommen, warum solltest du das tun? Ich habe auch mal einen Short aufgenommen zu der sinnvollen Anzahl an Seiten der Projektdokumentation. Wenn du eine erlaubte Vorgabe von 15 Seiten hast, warum willst du 13 abgeben? Das ist dumm, weil wenn du irgendwie eine schlechtere Note als 100 Prozent bekommst, wirst du dich ja immer fragen, so, hm, hat es an den zwei Seiten gelegen? Hätte ich noch was unterbringen können, was mir die Note verbessert hätte? Und die Antwort ist wahrscheinlich ja. Das heißt, hier ist es genauso. Warum willst du ein Projekt in weniger Zeit umsetzen? Dann kannst du ja weniger von deinem Beruf, von deinen Fähigkeiten zeigen, als jemand, der die 80 Stunden ausgereizt hat. Also du machst dich ja schlechter damit. Du stellst dich ja unter jemand anderen, der die Zeit ausgenutzt hat. Also warum solltest du das tun? Ist ja dumm einfach. Deswegen mach es nicht. Und in einigen Projektanträgen habe ich schon sowas gelesen, wie eine Pufferzeit eingeplant. Sowas wie, ich weiß ja nicht, was passiert. Ich kann ein Projekt nicht 100% perfekt genau planen, auch wenn es nur 80 oder 40 Stunden sind. Deswegen plane ich zwei Stunden Puffer ein, vier Stunden Puffer ein. Und auch hier wieder, wie bei sehr, sehr vielen anderen Dingen auch, kann das von deiner IHK abhängen, ob das okay ist oder nicht. Ich habe schon davon gehört, dass einige IHK’en sogar fordern, dass man einen Puffer einplant.
[7:23] Also das ist wieder völlig unterschiedlich. Wenn das bei mir jemand einplanen würde, würde ich einen Antrag ablehnen. Die Zeit ist komplett zu verplanen. Ende. Weiß ich, dass das unrealistisch ist? Ja. Will ich, dass jemand dann sagt, ja, ich plane vier Stunden Puffer ein, habe also nicht meine ganze Zeit ausgereizt und irgendwie fülle ich die ja schon, weil ich gehe davon aus, dass meine Planung sowieso schrottig ist und die Puffer werden auf jeden Fall benutzt. Also was ist das wieder für eine Aussage für eine Abschlussprüfung? Also wenn ich zeigen soll, dass ich ein Projekt verplanen kann und von Anfang an sage, ich bin mir aber unsicher und plane Puffer ein.
[7:54] Also ich weiß, das ist in der Realität vielleicht so, aber dann müssen wir halt ein bisschen gucken, das ist eine Prüfungsleistung und da muss man halt vielleicht das Optimum rausholen. Ja, man kann das Pro und Kontra argumentieren. Ist der Puffer jetzt gut oder schlecht? Und das ist jetzt müßig, darüber nachzudenken. Im Zweifel fragst du, wie bei allen Themen deine IHK, ob da ein Puffer nötig ist oder ob du auch weniger Zeit einplanen kannst. Warum auch immer du das machen willst, ich habe es ja gerade erklärt. Aber wenn deine IHK konkrete Vorgaben dazu hat oder irgendwas erwartet, wäre es natürlich gut, das zu wissen. Und bei einigen, wie gesagt, ich habe es gehört, da muss halt Zeit X als Puffer eingeplant werden, weil man halt, also ich finde es ja auch irgendwo nachvollziehbar, man weiß, dass es sowieso unrealistisch ist, sie planen und dann plant man halt Puffer ein. Okay, trotzdem erwarten die dann aber am Ende, dass der Puffer auch ausgenutzt wird. Also am Ende muss man trotzdem die 80 Stunden wieder gefüllt haben sinnvoll. Also das ist alles, ach, das ist auch alles ein bisschen konstruiert hier. Naja, es ist ja nun mal einfach eine Prüfungsleistung.
[8:49] So, okay. Dann sollte also normalerweise, wenn du dir nicht sicher bist oder dein IHK weiß das selber nicht oder sagt es dir nicht oder steht nicht im Internet oder wie auch immer, sollte es spätestens beim Prüfen des Projektantrags auffallen, wenn ein Prüfer, eine Prüferin den Antrag ablehnt und sagt, hier ist ein Puffer einzuplanen oder nicht, beziehungsweise planen sie die ganzen 80 Stunden ein, so wie wir das machen, dann weiß es halt. Und wenn dein Antrag durch ist, dann weißt du, dass du es richtig gemacht hast. Problem ist, wenn der Antrag abgelehnt wird und du ihn überarbeiten musst, dann brauchst du halt eine gewisse Zeit für die Überarbeitung und die erneute Prüfung und das geht alles von deiner Projektzeit ab. Deswegen würde ich gucken, dass du dich vorher informierst und den Antrag gleich so einreichst, dass er einfach genehmigt wird. Weil sonst machst du dir ohne Ende noch mehr Zeitdruck, weil du darfst ja erst mit dem Projekt anfangen, wenn dein Antrag genehmigt ist. Und wenn du noch einen neuen einreichen musst, dann dauert das teilweise zwei, manchmal sogar vier Wochen, bis du wieder ein Feedback kriegst. Und das geht natürlich alles von deiner Projektzeit ab. Deswegen informiere dich einfach vorher.
[9:43] So, und was du auch nicht machen kannst, das gibt es, hast du vielleicht schon mal ein paar Beispieldokus gesehen, auf meiner Website habe ich auch ein paar Beispieldokumentationen, da gibt es ein, ab und zu gibt es da mal ein Kapitel Abweichungen vom Projektantrag, daran könnte man begründen, warum man Dinge anders gemacht hat im tatsächlichen Projekt, wie als man sie auch im Projektantrag geplant hat, aber da kannst du auch nicht sagen, ja, Abweichen vom Projektantrag habe ich für mein Projekt 100 Stunden gebraucht. Nein, das geht nicht. Wenn dein Projekt mit 80 Stunden genehmigt ist, dann hast du auch 80 Stunden einzuhalten. Und Gesetz erlaubt sowieso nicht mehr. Das heißt, da kann man sich nicht rausreden und sagen, ja, ich habe es ja in die Doku geschrieben, ich habe mehr gebraucht und deswegen haben die mir jetzt 100 Stunden erlaubt. Nein, ist nicht der Fall. Dann würdest du im Zweifel, wenn du einen bösen Prüfungsausschuss hast, einfach durchfallen, weil du hast die Vorgaben nicht eingehalten. Also, halte dich dran und versuch nicht da irgendwie drum herum zu reden. Denn wenn du wirklich realistisch dein Projekt planen solltest und das wirklich mit dieser naiven Einstellung an deine Projektarbeit rangehst, dann ist es tatsächlich auch so, meinst du, du kannst es wirklich auf eine Stunde genau planen? Meinst du, 81 Stunden oder 80 Stunden sind dann wirklich so ein Riesenunterschied?
[10:54] Es ist sowieso alles unrealistisch. Das heißt, geh einfach von den 80 bis 40 Stunden aus und guck, dass du einfach genau bei der Zahl landest und dann ist dieses Prüfungsding einfach durch. So, sollte es jetzt aber dazu kommen, dass du während des Projektablaufs in irgendeiner Phase, die du da geplant hast, mehr Zeit brauchst, als du geplant hast, das wäre ja gefährlich, weil dann würdest du über die 80 Stunden kommen, dann kommt der magische Feen-Zauberstab und der, sorgt dann dafür, dass in einer anderen Phase, die später kommt, einfach ein bisschen Zeit eingespart wird und dann landest du einfach bei 40 oder 80 Stunden. So machst du das. Das heißt, wenn du also tatsächlich realistisch irgendwo mehr Zeit brauchst, dann musst du einfach dafür sorgen, dass du das magischerweise in einer anderen Phase wieder einsparst. So Klassiker ist dann so ein Soll-Ist-Vergleich. In der Projektdokur so steht, ja, in der Planungsphase habe ich etwas mehr Zeit gebraucht, weil der Prozess doch viel komplizierter war als erwartet. Dafür konnte ich in der Implementierungsphase die Zeit wieder einsparen, weil ich mir ja so viele Gedanken im Vorfeld gemacht habe. Blablabla. Wir wissen alle, dass das Bullshit ist. Sorry, ich muss das mal ganz offen sagen.
[11:59] Das passt einfach nicht. Und ich weiß, dass die meisten Prüflinge deutlich länger an ihrer Projektarbeit sitzen als die erlaubten 40 oder 80 Stunden. Machen wir uns da mal nichts vor. Vor allem, weil man auch die Zeit für die Projektdokumentation mit in diesen Zeitraum rein planen muss bei den meisten IHK. Da habe ich auch schon eine Podcast-Episode dazu gemacht. Das ist so unrealistisch. Es ist halt ein bisschen ein Prüfungskonstrukt hier. Trotzdem musst du dann, weil du das jetzt ja dann weißt, dich halt exakt an diese Vorgaben halten und magischerweise geht das am Ende alles auf. Dein Projekt wird perfekt umgesetzt und du sparst hier was ein, was du an anderer Stelle gut wieder investieren kannst, sodass du unterm Strich wieder genau auf 40 oder 80 Stunden landest. Das ist die Vorgabe. Das hätten wir gern.
[12:41] Ist das ein bisschen realitätsfern? Ja. Habe ich schon mal irgendein Projekt gesehen, wo es eine Abweichung gab, wo mehr Stunden rauskamen oder weniger und der Prüfling hat bestanden und eine Topnote bekommen? Nein. Also ich wäre nicht an deiner Stelle der Erste oder die Erste, der oder die es probieren möchte. Deswegen lass es einfach. Plan die Zeit genauso ein wie vorgegeben und dann passt das. Das ist mein Fazit für heute. Also Frage beantwortet. Musst du die Stunden exakt einhalten? Meine Antwort ja.
[13:11] Und das war’s für heute. Bis zum nächsten Mal.
Die Prüfungszeit beträgt für die betriebliche Projektarbeit und für die Dokumentation mit praxisbezogenen Unterlagen höchstens 80 Stunden.
Im ersten Teil hat der Prüfling nachzuweisen, dass er in der Lage ist, […] die Planung und Durchführung des Projektes anforderungsgerecht zu dokumentieren.
Diese Formulierungen lassen sich unterschiedlich auslegen:
Eine Auslegung ist, dass damit auch die finale Projektdokumentation für den Prüfungsausschuss gemeint ist.
Die andere Auslegung ist, dass hier die fachliche Dokumentation gemeint ist, die ohnehin zum Projekt gehört, z.B.:
Entwickler:innen-Dokumentation
Benutzerhandbücher
Installationsprotokolle
Checklisten
Netzpläne
Nach dieser zweiten Sichtweise gehört die fachliche Dokumentation zum echten Projekt, nicht aber das spezielle Prüfungsartefakt für den Ausschuss.
Es ist eigentlich offensichtlich, dass die vorgegebenen Projektzeiten oft schon für die eigentliche Umsetzung knapp sind. Wenn dann zusätzlich noch die vollständige Projektdokumentation in dieser Zeit erstellt werden soll, finde ich das sehr unrealistisch. Besonders kritisch sehe ich, dass manche IHKen für die Dokumentation nur etwa 10 bis 15 Prozent der Gesamtzeit vorsehen. Das wären bei 80 Stunden nur 8 bis 12 Stunden, bei 40 Stunden sogar nur 4 bis 6 Stunden.
Der DIHK hat eine Empfehlung beziehungsweise Vorgabe herausgegeben, nach der die Zeit für die Projektdokumentation mit eingeplant werden soll. Deshalb ist die Tendenz eher so, dass viele IHKen diese Zeit inzwischen in die Projektzeit einrechnen.
Trotzdem gibt es unterschiedliche Regelungen je nach Region:
Nicht in der Zeit enthalten: z.B. Regensburg, Bayreuth, Stuttgart
In der Zeit enthalten: z.B. Oldenburg, Gera, Berlin, Bonn
Beispiele
Umsetzungsempfehlung DIHK: drin mit 20%, https://www.ihk.de/blueprint/servlet/resource/blob/6945168/0424ce44eab4c49eab8b0c078fe7d796/dihk-umsetzungshilfe-it-berufe-data.pdf
Regensburg und Bayreuth: nicht drin, https://www.ihk.de/blueprint/servlet/resource/blob/6637094/a7a0c7a26a07c581efc8f6784bdf0c3c/it-berufe-hinweise-stand-15-07-25-data.pdf
Stuttgart: nicht drin, "Auch das reine Dokumentieren des Projektverlaufs gehört zur Zeitplanung (nicht die Erstellung und Ausgestaltung der finalen Datei für den Prüfungsausschuss).", https://www.ihk.de/stuttgart/fuer-azubis/pruefungen/formulareneu6359/it-berufe-infos-ap2-6705038
Berlin und Bonn, drin 15%, https://www.ihk-bonn.de/fileadmin/dokumente/Downloads/Ausbildung/IT-Berufe/IT-Handreichung_IHK_Bonn_Rhein-Sieg_2.pdf
In Oldenburg lehnen wir Projektanträge ab, wenn die Dokumentationszeit nicht in der Planung enthalten ist. Der Grund dafür ist die formale Vergleichbarkeit: Wer die Doku-Zeit nicht einplant, hätte auf dem Papier mehr Zeit für die eigentliche Entwicklung als andere Prüflinge.
Prüfe zuerst die Vorgaben deiner eigenen IHK.
Suche auf der Website nach Handreichungen, Merkblättern oder FAQ.
Wenn du nichts findest, frage direkt nach, z.B. per E-Mail oder telefonisch.
Wenn du keine klare Auskunft bekommst, ist es sinnvoll, die Zeit für die Projektdokumentation vorsichtshalber mit einzuplanen.
Auch wenn die Regelung kritisch gesehen wird, ist die wichtigste Empfehlung, dich an die Vorgaben deiner IHK zu halten. So vermeidest du formale Probleme, z.B. eine Ablehnung deines Projektantrags. Wenn dein Antrag genehmigt wird, kannst du davon ausgehen, dass deine Zeitplanung formal passt.
Die Frage, ob die Projektdokumentation zur Projektzeit zählt, lässt sich nicht allgemeingültig beantworten. Viele IHKen rechnen sie inzwischen mit ein, andere nicht. Weil die Regelung regional unterschiedlich ist und der DIHK eher die Einplanung unterstützt, ist der sicherste Weg: bei deiner IHK nachfragen und die dortige Vorgabe konsequent umsetzen.
[0:21] Heute geht es um eine Frage, die sich viele Prüflinge stellen, wenn sie vor ihrer Projektdokumentation stehen. Und zwar soll ich die Zeit zum Erstellen der Projektdokumentation mit in die Bearbeitungszeit der Projektarbeit einplanen? Also ich erstelle die Projektdokumentation für den Prüfungsausschuss, das 20, 30, 40, 50 Seiten Dokument. Das muss ich ja auch irgendwie zusammenschreiben, formatieren etc. Die Zeit, die ich dafür brauche, gehört das mit in die 80 Stunden bzw. 40 Stunden meiner Projektzeit oder ist das extern und ich kann da so viel Zeit investieren, wie ich will? Und ja, es ist leider wieder so, dass die Antwort ist, es kommt drauf an. Und zwar auf die IHK. Wir haben ja 79 verschiedene in Deutschland. Und wie bei vielen anderen Themen, wo man sich fragen könnte, warum wird das nicht einfach zentral geregelt, ist es auch hier wieder so, dass jede IHK macht, was sie will, beziehungsweise machen kann, was sie will.
[1:22] Kurz vorweg, die meisten IHK, die ich recherchiert habe, ich habe nicht alle 79 recherchiert, nein, aber die meisten, die ich gefunden habe, erwarten, dass die Doku jetzt in der Projektzeit geschrieben wird. Und kurz vorweg, bevor ich jetzt in die Details gehe, meine persönliche Meinung. Ich finde das total schwachsinnig. Ich finde es total bescheuert, dass wir in 40 oder 80 Stunden, was ja sowieso sehr, sehr wenig ist, um ein einigermaßen passendes Projekt umzusetzen und wo wir uns alle.
[1:52] Ganz sicher sind, dass die meisten Prüflinge diese Zeit eh nicht einhalten, weil ihr Projekt deutlich länger dauert als diese 40 oder 80 Stunden, dass man dann auch noch erwartet, dass sie eine umfangreiche Projektdokumentation und bei manchen IHK’en sind das wirklich 50 Seiten mit Inhaltsverzeichnis, mit Anhang, mit Bildern, mit allem Pipapo, dann noch irgendwie damit reinquetschen. Und das muss natürlich dann an einen einigermaßen realistischen Anteil haben. Die Projektdoku darf natürlich nicht 90 Prozent der Zeit in Anspruch nehmen. Das heißt, dann gibt es so Vorgaben wie zwischen 10 und 15 Prozent. Das sind dann vielleicht, sagen wir mal, zwölf Stunden, also anderthalb Arbeitstage. Und dann kann man sich mal überlegen, wie realistisch das ist, dass ich 50 Seiten in anderthalb Arbeitstagen zusammenkriege. Ohne Fehler und wunderbar alle Referenzen aufgelöst und Bilder benannt und in der richtigen Reihenfolge und alles. Also das ist einfach utopisch unmöglich und absolut schwachsinnig, das in diese Zeit mit einzuplanen. Das ist meine persönliche Meinung zu diesem Thema. Und jetzt kommen wir zu der Meinung der IACAN. Und leider sehen viele IACAN das ein bisschen anders und sagen, nö, ist absolut sinnvoll und total realistisch, dass Prüflinge solche Dokumente auch noch innerhalb ihrer 40 oder 80 Stunden schreiben. Und deswegen ist das einzuplanen.
[3:06] So, vorweg, bevor wir jetzt weiter in die Details gehen. Das eine ist, was du laut Vorgabe zu planen hast. Das andere ist die reale Welt. Und wir sind uns eh alle einig, dass die Projekte sowieso meistens nicht in der Zeit umsetzbar sind. Zumindest, wenn du einigermaßen eine vernünftige Note haben willst. Deswegen, ehrlich gesagt…
[3:26] Drauf und schreibt das einfach außerhalb der Projektzeit. Und das tut mir in der Seele weh, dass ich Leuten empfehlen muss, die Regeln hier zu brechen. Ich bin ja auch Prüfer und muss dann am Ende bewerten, ob das Projekt hätte realistisch umgesetzt werden können, um dann eine Note daneben zu schreiben. Aber wenn du wirklich alles, was für dein Projekt nötig ist, in den 40 oder 80 Stunden ausschließlich umsetzen willst, dann machst du ein echt schlechtes Projekt. Das kann ich dir so schon mal sagen. Also Plan E, mehr Zeit für dein Projekt ein, als erlaubt ist. Ein offenes Geheimnis, das ich jetzt hier einfach mal ausspreche. Und wenn du dann noch 50 Seiten in anderthalb Tagen schreiben willst, also zum Leid, absolut utopisch und lächerlich. Gut, kommen wir nochmal jetzt zurück zum eigentlichen Thema. Warum gibt es überhaupt Missverständnisse? Warum kann es sein, dass die eine IHK das erlaubt und die andere nicht, dass die Zeit außerhalb der Projektzeit läuft? Es gibt ja eine Berufsverordnung und für jeden der IT-Berufe gibt es eine, für den Fachinformatiker zum Beispiel eine, die alle vier Fachrichtungen umfasst. Für die anderen Berufe gibt es eigene Berufsverordnungen. Und da steht dann im Text so etwas drin, dass man eben so ein Projekt umsetzen muss und das auch dokumentieren muss. Und da steht dann wortwörtlich zum Beispiel in Paragraf 12 Absatz 2, der Prüfling hat eine betriebliche Projektarbeit durchzuführen und mit praxisbezogenen Unterlagen zu dokumentieren.
[4:50] Das ist ein Punkt. Dann die Prüfungszeit beträgt für die betriebliche Projektarbeit und für die Dokumentation mit praxisbezogenen Unterlagen höchstens 80 Stunden. Ich bin jetzt beim Anwendungsentwickler, wie du gerade merkst, die anderen Berufe haben nur 40 Stunden. Und dann gibt es noch den Satz, im ersten Teil hat der Prüfling nachzuweisen, dass er in der Lage ist, kleine Auslassung, die Planung und Durchführung des Projektes anforderungsgerecht zu dokumentieren. Du siehst, ich habe jetzt hier mal ein paar Sätze rausgegriffen, wo der Begriff Dokumentation oder Dokumentieren drinsteht. Und jetzt kann man sagen, wenn man das so liest, ja, praxisbezogene Unterlagen, Dokumentation in höchstens 80 Stunden, ja, hört sich ja so an, als würde das da in die 80 Stunden reingehören. Ja, das kann man jetzt so sehen, weil da einfach der Begriff Dokumentation steht. Aber in vernünftigen IT-Projekten gibt es natürlich auch als Teil des Projekts eine Dokumentation. Zum Beispiel bei Anwendungsentwicklerinnen, für die Entwicklerkolleginnen, die sich mal in das Projekt einarbeiten sollen. Zum Beispiel ein Klassendiagramm. Oder bei Admins, die da irgendwie einen Server aufsetzen. Vielleicht ein Installationsprotokoll oder eine Checkliste, was man machen muss, um den Server zu klonen. Oder was auch immer. Oder ein Netzplan oder Sonstiges. Und wenn wir irgendwie eine Software bauen, zum Beispiel für Endanwenderinnen, da muss es vielleicht noch ein Benutzerhandbuch geben. Das ist auch eine Dokumentation.
[6:10] Und jetzt steht hier auch betriebliche Projektarbeit und die Dokumentation mit praxisbezogenen Unterlagen. Und deswegen interpretiere ich, und da bin ich übrigens nicht alleine, auch viele andere Prüfende interpretieren da rein, dass es hier um die Dokumentationsteile geht, die ganz normal als Teil des Projekts umgesetzt werden. Also Benutzer, Anwender, Admin, was auch immer Dokumentation. Und nicht das Prüfungsartefakt, was für den Prüfungsausschuss da ist. Ich meine, die Abschlussprüfung hat doch den Zweck, eine praxisbezogene Projektarbeit umzusetzen. Man soll zeigen, dass man nicht nur was aus dem Buch lernen kann, sondern dass man es auch umsetzen kann. Dass man ein Projekt von A bis Z umsetzt, inklusive Anforderungsaufnahme, lalalala, und inklusive Dokumentation, die wir natürlich in echten Projekten alle ständig machen, beziehungsweise durch KI machen lassen jetzt in Zukunft, wie auch immer. Auf jeden Fall gehört das einfach mit zum Projekt dazu und das soll man ja auch zeigen. Das soll ja auch ein echtes Projekt sein. Also wieso sollte man jetzt die Zeit, die man braucht, weil das hier eine Prüfungsleistung ist und dieses besondere Prüfungsartefakt hier zu erstellen ist, warum sollte man die Zeit mit in die 80 Stunden einplanen oder 40?
[7:16] Mir erschließt sich das nicht. Vor allem, wir haben ja in der Neuordnung 2020 die Zeit fürs Projekt erhöht. Von 70 auf 80 Stunden, beziehungsweise von 35 auf 40. Und jetzt kommt irgendeine IHK und sagt, ja, Moment, von den 10 zusätzlichen Stunden, liebe Anbietungsentwicklerinnen, müsst ihr aber 15 gleich wieder runternehmen, weil ihr müsst jetzt auch noch die Doku mit in die Zeit reinquetschen. So, das ist einfach kompletter, ich bin ganz ehrlich Bullshit. Das heißt, ich habe nach der Neuordnung weniger Zeit für mein Projekt als vorher, weil ich jetzt auch noch diese komische Prüfungsgeschichte damit unterbringen muss. Also ich kann mich da herrlich drüber aufregen, weil ich finde das so bescheuert, dass das ganze Ding Abschlussbreit steht sowieso ständig zur Diskussion, weil es unrealistisch ist und die Zeiten passen nicht und was. Und dann muss man da noch jetzt 15 Stunden abziehen, weil man eine Doku braucht. Also ich finde das ganz beknackt. Auf jeden Fall, es ist jetzt so, dass andere Leute halt der Meinung sind, dass in diesem Gesetzestext steht, ja, das ist offensichtlich Dokumentation, Projektdokumentation, also gehört das da rein, blablabla.
[8:12] Und übrigens, ich bin nicht alleine mit der einen Meinung, es gibt aber auch viele, die der anderen Meinung sind, dass die Projektdokumentationszeit halt mit da reingehört. Unter anderem auch der DIHK, also der Deutsche Industrie- und Handelskammer Tag, der hat tatsächlich eine offizielle Empfehlung herausgegeben, beziehungsweise Ansage, ich weiß es gar nicht, oder Vorgabe einfach, dass die Zeit da nun mit einzuplanen ist. Also von daher kann ich jetzt hier schlau schnacken. Trotzdem würde ich dir den direkten Tipp geben, frag bei deiner eigenen IHK nach, was da die Vorgaben sind. Denn ich weiß, Stand heute, ich nehme das gerade Mitte 2026 auf, kenne ich mindestens für beide Seiten zwei verschiedene IHK, die es so machen oder eben auch anders machen. Das heißt, wie bei vielen formalen Fragen zu deiner Projektarbeit gilt, frag deine IHK, was da Vorgabe ist. Wenn du keine Vorgabe findest, zum Beispiel im Internet, auf der Website irgendwelche Handreichungen, Merkblätter, was auch immer zur Abschlussdoku, dann frag nach, dann ruf an, dann schick eine E-Mail. Und wenn du dann immer noch keine Aussage kriegst, dann würde ich dir tatsächlich empfehlen, plan die Zeit mit ein, weil meiner persönlichen Rechercherfahrung nach jetzt ist es so, dass die meisten IHK inzwischen die Zeit inklusive Projektdokumentation haben wollen und weil der DIHK das ja auch vorgegeben hat, wird das wahrscheinlich auch tendenziell die Richtung sein, wo die meisten IHK sich hin entwickeln werden, wenn sie da jetzt noch nicht sind.
[9:37] Okay, wenn man dann guckt, was soll man denn für eine Zeit einplanen? Die meisten IHKN geben irgendwas zwischen 10 und 15 Prozent der Zeit an. Das heißt, da wären wir irgendwo bei 8 bis 12 Stunden. Alles, was da drüber liegt, ist dann wieder, also ich beziehe das immer auf die Anwendungsentwickler, da kannst du jetzt runterrechnen auf Fisis, dann bist du bei 4 bis 6 Stunden. Ja, herzlichen Glückwunsch, schreib mal 50 Seiten in 6 Stunden. Also das ist, ja, okay, lassen wir das Thema.
[10:03] So, trotzdem musst du natürlich in deiner Projektarbeit die gute alte Dokumentation, die ich meine, erstellen für Benutzende und Entwicklerinnen und ich weiß nicht was. Das gehört natürlich trotzdem auch noch dazu.
[10:14] Und ich meine, auch da braucht man ja ein paar Stündchen für, wenn man ein vernünftiges Benutzernbuch schreiben will. Also da siehst du, dass das alles völlig irrelevant ist. Naja, irrelevant, weil unrealistisch. Ja, ansonsten solltest du, wenn du es falsch machst, in Anführungszeichen, eigentlich sofort beim Prüfen des Projektantrags ein Feedback bekommen. Bei uns in Oldenburg wurde diese Regelung umgestellt. Vor der Neuordnung war die Projektarbeit außerhalb der Zeit und man konnte quasi Stunden und Wochen investieren, um seine Projektarbeit zu optimieren, sage ich mal. Inzwischen ist es explizit genauso, dass die IHK will, dass es in den 80 Stunden oder 40 Stunden mit drin ist. Und deswegen würden wir tatsächlich auch Projektanträge, wo das nicht der Fall ist, ablehnen. Also wenn jemand kommt und sagt, ich verplane hier meine 80 Stunden für die Softwareentwicklung komplett und die Doku ist nicht mit drin, dann lehnen wir den Projektantrag ab, weil das nicht den formalen Anforderungen entspricht. Das kannst du dir auch vorstellen, kommt ein Asubi, der quasi 10 bis 8 bis 12 Stunden mehr Zeit hat, Software zu entwickeln, weil dieses Prüfungsartefakt nicht eingepreist ist und jemand, der das dann macht und sich an die Regeln hält, hat weniger Zeit und kann demnach ja auch eigentlich nur ein kleineres Projekt umsetzen, was also vielleicht zu einer schlechten Note führt und das wäre natürlich unfair. Deswegen ist es bei uns so, wird abgelehnt, wenn es nicht zur Anforderung passt. Andere eher kann, vielleicht gucken die da gar nicht drauf oder winken das einfach durch oder wie auch immer, es dreht auch jeder sein eigenes Ding.
[11:36] Gut, ich habe einfach mal ein paar Beispiele mitgebracht, was jetzt Stand Mitte 2026 so ist. Die Umsetzungsempfehlung des DIHK und da steht drin, 20% der Zeit sollen eingeplant werden, sogar noch mehr. Ich verlinke das auch gerne mal in den Shownotes, dann kannst du das einfach angucken.
[11:53] Ich habe dann zum Beispiel zwei IHK gefunden, Regensburg und Bayreuth. Die sagen explizit, die Zeit ist nicht mit drin. Dann gibt es in Stuttgart, gut, Baden-Württemberg, die machen eh, was sie wollen. Das kennen wir ja schon von den Prüfungen. Aber da steht zum Beispiel auch, dass es nicht mit drin ist. Da steht dann zum Beispiel auch, das reine Dokumentieren des Projektverlaufs gehört zur Zeitplanung, aber nicht die Erstellung und Ausgestaltung der finalen Datei für den Prüfungsausschuss. Da ist also explizit nochmal das Prüfungsartefakt wieder ausgenommen. Ich habe natürlich meine eigene IHK Oldenburg, da ist es mit drin. Da haben wir 15 bis 20 Prozent angesetzt. Oh, ich hatte 10 bis 15 im Kopf. Na gut, ist egal, sogar noch mehr. Also 20 Prozent von 80 Stunden, das wären 16 Stunden. Das wären zwei komplette Arbeitstage, die mir fehlen. Ja, gut, egal. Und dann haben wir zum Beispiel noch Gera, sind es auch 20 Prozent. Berlin und Bonn sind 15 Prozent der Zeit vorzusehen. Also ich habe jetzt hier schon, ich habe für jede Seite sogar drei, vier Beispiele. Da siehst du, es geht mal so, mal so, je nachdem, bei welcher IHK du bist. Deswegen, ich empfehle dir dringend, frag bei deiner konkreten IHK nach, was muss ich machen. Und sonst, ja, siehst du spätestens beim Antrag, wenn der genehmigt ist, dann weißt du, hast du alles richtig gemacht.
[13:05] Also, wenn du nicht weißt, was Sache ist, ich würde dir empfehlen, nehme es mit rein in die Zeit. Die meisten IHKern werden es so machen, weil der DIHK es halt auch empfiehlt oder vorgibt. Und du kannst dich darüber ärgern und ärgern, so wie ich. Oder du sagst einfach, ja komm, trage ich da halt eine Zeit ein. Guckt sowieso keiner drauf. Die ganzen Zeiten sind sowieso unrealistisch. Und dann setzt du es einfach um. Ja, das war jetzt heute mein Rant zu diesem Thema, weil ich finde diese Entscheidung einfach so beknackt. Ich kann es gar nicht in Worte fassen. Aber gut, am Ende ist es auch nur eine Zahl. dir steht und weil wir eh alle wissen, dass das ausgedachte Zahlen manchmal auch sind, ist es vielleicht auch am Ende gar nicht so schlimm. Also halt dich einfach an die Vorgaben. Dann kannst du wenigstens nicht wegen solcher Formalia, weil du irgendwo eine Stunde zu wenig geplant hast, irgendwo, also durchfallen wirst du deswegen sowieso nicht. Aber zum Beispiel könnte der Progdantrag ja abgelehnt werden, dann musst du neu machen und dann hast du weniger Zeit für die Umsetzung wegen der Frist und tralla. Also ja, ich empfehle dir, frag nach, halt dich daran und dann war es das zu diesem Thema. Und ja, jetzt weißt du auch, wie ich das sehe und dass es wie viele andere Themen auch leider nicht deutschlandweit einheitlich geregelt ist, sondern viele IHK, einfach ihre eigenen Sachen durchziehen.
[14:15] Jo, das war’s für heute. Ich sag bis zum nächsten Mal. Ciao.
Gesamtergebnis von Teil 1 und Teil 2 mindestens ausreichend
Ergebnis von Teil 2 mindestens ausreichend
In mindestens drei Prüfungsbereichen von Teil 2 mindestens ausreichend
In keinem Prüfungsbereich von Teil 2 ungenügend
Für AP2 heißt das praktisch:
Du hast vier Prüfungsbereiche in AP2:
Projekt
schriftlicher Bereich 1
schriftlicher Bereich 2
WISO
In mindestens drei von diesen vier Bereichen musst du mindestens eine 4 haben.
Wenn das Projekt bestanden ist, darfst du in den drei schriftlichen Prüfungen höchstens einmal durchfallen.
Das bedeutet:
Eine 5 in einer schriftlichen Prüfung kann noch okay sein.
Zwei 5en in den schriftlichen Prüfungen reichen nicht mehr.
Eine 6 in einem Prüfungsbereich von Teil 2 ist ebenfalls nicht erlaubt.
Eine MEP wird relevant, wenn du durch eine schriftliche Prüfung in AP2 das Bestehen verfehlst (siehe Mündliche Ergänzungsprüfung).
Typische Fälle:
zwei 5en in den schriftlichen Prüfungen → eine davon muss ausgeglichen werden
eine 6 → diese muss mindestens so verbessert werden, dass sie nicht als 6 stehen bleibt
Dabei gilt aber immer:
Du musst mit der MEP überhaupt noch rechnerisch bestehen können.
Wenn das nicht mehr möglich ist, gibt es keine MEP.
Rein rechtlich gilt:
Der Prüfling beantragt die MEP selbst.
In der Praxis kann es sein, dass die IHK das automatisch anstößt. Verlassen solltest du dich darauf aber nicht. Wenn deine Noten knapp oder kritisch sind, solltest du direkt bei deiner IHK nachfragen, wie das bei dir geregelt ist.
Die MEP ist nur in einem einzigen schriftlichen Prüfungsbereich möglich.
Voraussetzungen:
der Bereich muss zu den schriftlichen Prüfungen von AP2 gehören
du musst dort schlechter als ausreichend sein, also unter 50 Punkten
die MEP muss für das Bestehen der Abschlussprüfung überhaupt noch etwas ändern können
Nicht möglich ist:
MEP im Projekt
MEP in mehreren Prüfungsbereichen
MEP zur reinen Notenverbesserung
Die MEP dauert in der Regel 15 Minuten.
Das Ergebnis wird zusammen mit der bisherigen schriftlichen Note im Verhältnis 2:1 verrechnet:
schriftliches Ergebnis zählt zweifach
Ergebnis der MEP zählt einfach
Das neue Ergebnis im Prüfungsbereich wird also so berechnet:
(schriftlich × 2 + MEP) / 3
Die MEP hat nur begrenzte Hebelwirkung.
Beispiele:
Bei 40 Punkten in der schriftlichen Prüfung brauchst du 70 Punkte in der MEP, um auf 50 Punkte insgesamt zu kommen.
Bei 30 Punkten brauchst du 90 Punkte in der MEP, um noch auf 50 Punkte zu kommen.
Bei 25 Punkten brauchst du sogar 100 Punkte in der MEP, um auf 50 Punkte zu kommen.
Ab 24 Punkten oder weniger kannst du rechnerisch in diesem Prüfungsbereich nicht mehr auf 50 Punkte kommen.
Deshalb ist das Ziel bei einer sehr schlechten 6 oft nicht mehr, diesen Bereich noch auf eine 4 zu bringen, sondern die 6 wenigstens auf eine 5 zu heben, damit die Prüfung insgesamt vielleicht noch bestanden werden kann.
Dazu gibt es keine einheitliche Vorgabe in der Berufsverordnung. Deshalb ist der Ablauf von IHK zu IHK unterschiedlich.
Möglich ist zum Beispiel:
MEP direkt am Tag der mündlichen Prüfung
separater zusätzlicher Termin
rein mündliches Fachgespräch
kurze Vorbereitung auf Aufgaben
Aufgaben an Tafel oder Papier mit anschließendem Gespräch
Entscheidend ist:
Es muss eine mündliche Prüfung sein.
Sie soll etwa 15 Minuten dauern.
Alles Weitere kann je nach IHK und sogar je nach Prüfungsausschuss unterschiedlich sein.
Deshalb ist der wichtigste praktische Hinweis:
Frag direkt bei deiner IHK nach.
Verlass dich nicht auf Berichte aus dem Internet oder auf Erfahrungen von anderen Prüflingen.
Die Fragen müssen zu dem Prüfungsbereich passen, in dem du durchgefallen bist.
Beispiele:
bei WISO etwa Themen wie Arbeitsrecht, Tarifverhandlungen oder Jugendarbeitsschutz
bei einer fachlichen Prüfung etwa SQL, Pseudocode, UML oder andere Inhalte des jeweiligen Prüfungsbereichs
Früher konnte der Themenbereich enger eingegrenzt werden. Das ist heute nicht mehr so. Maßgeblich ist jetzt der gesamte Prüfungsbereich, in dem du durchgefallen bist.
Das bedeutet:
Du musst dich breit auf alle Themen dieses Bereichs vorbereiten.
Du kannst nicht davon ausgehen, dass nur ein einzelnes Lieblingsthema gefragt wird.
Die inhaltliche Vorbereitung ist im Grunde dieselbe wie für die schriftliche Prüfung, in der du durchgefallen bist.
Sinnvoll ist dabei:
alte Prüfungen durcharbeiten
typische Themen des Prüfungsbereichs sammeln
Antworten mündlich formulieren und erklären üben
mit einer anderen Person üben, zum Beispiel mit dein:e Ausbilder:in, Lehrkraft oder einer erfahrenen Person
Wichtig ist der Unterschied zur schriftlichen Prüfung:
In der MEP musst du die Inhalte mündlich verständlich erklären können.
Du solltest also nicht nur Aufgaben lösen, sondern auch üben, wie du Begriffe, Abläufe und Zusammenhänge in Worten erklärst.
Die MEP ist keine einfache Notenrettung, weil die 2:1-Gewichtung rechnerisch viel verlangt. Trotzdem kann sie eine echte Chance sein, wenn das Bestehen noch möglich ist.
Dabei gilt:
Die Prüfenden wollen in der Regel nicht, dass du scheiterst.
In einer mündlichen Prüfung gibt es oft mehr Möglichkeiten, durch Nachfragen und Umschreibungen noch zu zeigen, was du kannst.
Trotzdem bleibt die MEP deine letzte Chance, deshalb solltest du dich gezielt vorbereiten.
Die MEP betrifft nur schriftliche Prüfungsbereiche von AP2.
Sie ist nur möglich, wenn du in einem Bereich unter 50 Punkten liegst und damit das Bestehen noch retten kannst.
Sie dauert etwa 15 Minuten.
Die Bewertung erfolgt im Verhältnis 2:1 zugunsten der bisherigen schriftlichen Note.
Der genaue Ablauf ist nicht einheitlich geregelt und hängt von deiner IHK ab.
Wenn deine Noten kritisch sind, solltest du sofort selbst bei deiner IHK nachfragen, wie es weitergeht und ob du etwas beantragen musst.
Für die Vorbereitung solltest du die Themen der betroffenen schriftlichen Prüfung wiederholen und vor allem das mündliche Erklären trainieren.
[0:21] Hallo und herzlich willkommen zur 197. Episode des IT-Brufe-Podcasts. Mein Name ist Stefan Macke und heute geht es um ein Thema, das ich vor langer, langer, langer Zeit schon mal im Podcast besprochen habe. Allerdings noch auf Basis der alten Berufsverordnung. Und die wurde ja 2020 komplett über den Haufen geworfen. Deswegen ist es dringend Zeit, das mal zu aktualisieren. Und zwar geht es heute um die mündliche Ergänzungsprüfung, die MEP. Was ist das? Warum braucht man das? Wann muss ich da rein? Wie wird die bewertet? Wie breite ich mich vor? Das soll heute das Thema sein. Die mündliche Ergänzungsprüfung betrifft vor allem die Prüflinge oder nicht nur vor allem, also nur die Prüflinge, die durch einen Teil, nee, nein, sorry, durch einen Bereich von Teil 2 der Prüfung durchgefallen sind. So, wir müssen aber genau auf die Begriffe hier achten.
[1:10] Die Abschlussprüfung besteht ja aus zwei Teilen, der AP1 und der AP2. Und diese Teile haben jeweils Prüfungsbereiche. Die AP1 hat nur einen Bereich, nämlich die schriftliche Prüfung, aber die AP2 hat mehrere Bereiche. Und zwar einmal das Projekt, das Abschlussprojekt, was man machen muss, was natürlich auch den größten Anteil an der Note hat. Und dann gibt es aber noch drei weitere Prüfungsteile in AP2. Und zwar die zwei berufsspezifischen Prüfungen. Für Armungsentwickler ist das zum Beispiel Entwickeln und Analysieren und Entwickeln von Algorithmen, heißt das, glaube ich. Und das andere Plan eines Softwareprodukts. Und für die anderen IT-Berufe heißen die halt irgendwie anders. Die weiß ich jetzt leider nicht alle auswendig. Und da gibt es auch den dritten Teil und das ist Wieso. Wirtschaft und Soziales, der ist ja für alle Berufe, nicht nur für IT-Berufe, sondern sogar für alle Berufe identisch. Und diese drei Prüfungsbereiche plus das Projekt, das sind die vier Prüfungsbereiche in AP2.
[2:03] Und wenn man durch diese schriftlichen Prüfungen, beziehungsweise eine davon oder auch zwei oder noch mehr, durchfällt, dann muss man eventuell in eine mündliche Ergänzungsprüfung, um diese schlechte Note auszugleichen. Darum geht es im Prinzip. Und was da jetzt genau die Voraussetzungen sind und wie so eine Prüfung abläuft, wenn man sich vorbereitet, das soll heute einmal das Thema sein. Es geht also darum, wenn ich eine schlechte Note habe, wenn ich irgendwo durchgefallen bin in einem der Prüfungsbereiche von AP Teil 2, wie läuft das denn ab und was mache ich da? Kurz schon mal vorweg, die AP 1, da kann man nicht durchfallen. Die AP 1, wenn du da eine schlechte Note hast, ja, dann hast du leider Pech gehabt, die kannst du nicht wiederholen. Das heißt, egal ob du eine 6 sogar hast, vielleicht auch in AP 1, du kannst trotzdem deine Prüfung insgesamt bestehen und du hast auch keine Chance, die Note wieder auszugleichen. Wenn du eine 6 hast, dann steht die da. Und auch wenn du am Ende bestanden hast, steht die 6 trotzdem auf dem Säugnis. Deswegen kann ich hier nochmal dafür ganz wichtig plädieren. Bereite dich gut auf die AP1 vor. Diese Note kriegst du nie wieder ausgeglichen, wenn die schlecht ist. Außer du wiederholst die komplette Prüfung nochmal, also deine ganze Ausbildung. Und das willst du sicherlich nicht.
[3:12] Also AP1, da sind wir komplett raus. Egal wie schlecht die Note, da kannst und musst und darfst du nichts wiederholen. Wir reden hier nur über die schriftliche Prüfung von Teil 2. Das Projekt, wenn du da durchfällst, hast du auch ein Problem. Da muss man nochmal in einer gesonderten Episode vielleicht drüber reden. Da gibt es auch keine Ergänzungsprüfung, sondern es geht hier nur um die drei Prüfungsbereiche, die schriftlichen Prüfungen von Teil 2, also die beiden berufsspezifischen und Wieso.
[3:38] So, dann würde ich sagen, werfen wir doch mal einen Blick in unsere Berufsverordnung und schauen einfach mal, wann man überhaupt die Prüfung besteht und was dafür nötig ist und kommen dann irgendwie darüber zur mündlichen Ergänzungsprüfung. Da schauen wir einfach mal in die FI aus PF, also die Verordnung über die Berufsausbildung zum Fachinformatiker und zur Fachinformatikerin, die FI aus PF. Die gleichen Sachen, die ich jetzt erzähle, gelten für alle IT-Berufe. Also wenn ich jetzt für die Fachinformatiker das sage, gibt es natürlich genauso eine Berufsverordnung für die anderen IT-Berufe, die Kaufmännischen und den Systemelektroniker und so weiter, sind exakt identisch aufgebaut, wörtlich eins zu eins identisch, bis auf eine Kleinigkeit. Und das ist auch der Grund, warum es tatsächlich für alle vier Fachinformatiker.
[4:23] Jeweils einzelne Paragrafen für das Bestehen der Prüfung und die Münchner Gänzungsprüfung gibt. Denn der einzige Unterschied ist, dass diese Prüfungsdienstechnik Bereiche ja etwas anders heißen. Ich habe es ja gerade schon gesagt, für Amix und Mikla, Bereich 1 und 2 der schriftlichen Prüfung ist halt Algorithmik und Plan eines Softwareprodukts und für die anderen IT-Berufe heißen die halt anders. Und deswegen muss man diese Paragrafen, die ich jetzt vorlese, siebenmal doppelt und dreifach definieren, weil ja diese kleine Geschichte sich ändert, also einfach der Name der Prüfung.
[4:52] Und des Prüfungsbereichs. Und für IT-Systemelektroniker kommt noch dazu, dass es ein Sperrfach gibt, aber das ist eine andere Geschichte, das gibt es für die anderen Archieberufe nicht. Worum es jetzt heute hier geht ist, wann bestehe ich die Prüfung und wann muss ich in der MEP. Und die Idee ist für alle IT-Berufe identisch, auch wenn sie in unterschiedlichen Paragrafen definiert sind. Ich fange einfach mal an mit dem Anwendungsentwickler, weil der steht einfach ganz vorne, das sind die ersten Paragrafen. Das heißt, wenn du in die VIE aus Pf in Paragraf 16 schaust, dann gibt es da die Gewichtung der Prüfungsbereiche und Anforderungen für das Bestehen der Abschlussprüfung. Und für die anderen drei Fachrichtungen gibt es die auch, bloß halt ein paar Paragrafen später und du wirst sehen, die sehen eins zu eins identisch aus. Und wenn du einen ganz anderen IT-Beruf machst, dann guckst du halt in deine Ausbildungsverordnung und wirst das sicherlich auch finden, ob es jetzt Paragraf 16 ist oder 17 oder 23. Das wirst du wohl herausfinden, ja. Also es gibt einen Paragrafen, der sagt, wie sind die Prüfungsbereiche zu gewichten und wann besteht man die. Und für die Anwendungsentwicklung ist das halt in Paragraf 16 definiert. Und hier wird auch nochmal einmal darauf hingewiesen, dass es diese zwei Prüfungsteile gibt mit jeweils unterschiedlichen Bereichen. Und jetzt gucken wir uns den Absatz 2 an. Und da steht drin, die Abschlussprüfung ist bestanden, wenn die Prüfungsleistungen, Achtung, auch unter Berücksichtigung einer mündlichen Ergänzungsprüfung nach § 17, da werden wir dann ja gleich darauf eingehen, wie folgt bewertet worden sind. Also alles, was jetzt kommt, musst du immer so verstehen, dass du eventuell auch noch eine MEP einschiebst, um eine deiner Noten zum Beispiel höher zu ziehen, auszugleichen, wie auch immer. Aber grundsätzlich bestehst du die Prüfung, wenn.
[6:20] Du im Gesamtergebnis von Teil 1 und 2 mindestens ausreichend hast. Das heißt, du nimmst das Gesamtergebnis von Teil 1 und von Teil 2, rechnest das zusammen und guckst, dass du da über 50% kommst. Bist du mal so größer gleich 50, ne? Ab 50% hast du bestanden. Gesamtergebnis von beiden 50%. Dann Punkt Nummer 2, im Ergebnis von Teil 2 mit mindestens ausreichend. Das heißt, hier wird nochmal explizit gesagt, in Teil 2 musst du eine 4 haben, 50%. Teil 1 irrelevant. Du kannst in Teil 1 eine 6, eine 5 haben, völlig egal, solange du im Gesamtergebnis über 50% kommst, alles gut. Aber in Teil 2 musst du insgesamt alleine auf ausreichend kommen, auf 50%. Da kannst du nicht einzeln durchfallen und dann trotzdem die Prüfung bestehen, das geht nicht.
[7:06] Also Gesamtergebnis Teil 1 und 2 zusammen 4, Teil 2 alleine auch mindestens 4. Und jetzt kommt der wichtige Punkt für die MEP, in mindestens drei Prüfungsbereichen von Teil 2 mit mindestens ausreichend. Das heißt, wir gucken nochmal, welche Prüfungsbereiche gibt es. Wir haben deine beiden fachspezifischen schriftlichen Prüfungen, die Wieso-Prüfung als dritte schriftliche Prüfung und wir haben das Projekt. Das Projekt ist auch Bereich von Teil 2. Das heißt, du musst in all diesen vier Prüfungsbereichen in mindestens dreien davon eine 4 haben, also 50%. Und diese Ergänzungsprüfung kann man aber jetzt ja nur für die schriftlichen Prüfungen machen und nicht fürs Projekt. Deswegen gucken wir uns im weiteren Fall jetzt einfach mal nur diese drei Bereiche an. Und weil ja drei von vier bestanden sein müssen und wenn wir das Projekt jetzt ausklammern, musst du in mindestens zwei der drei schriftlichen Prüfungen durch sein. Ausreichend haben, 50%. Geh mal davon aus, dass du das Projekt auf jeden Fall bestehen musst und wenn du dann noch drei schriftliche Prüfungen hast, musst du in zwei davon mindestens eine vier haben. Anders formuliert heißt das, du kannst in einer schriftlichen Prüfung durchfallen, aber das war’s. Also zwei Fünfen, du bist raus.
[8:20] Und jetzt kommt Punkt Nummer 4 hier noch. In keinem Prüfungsbereich von Teil 2 darfst du ungenügend haben. Das wäre die 6. Also wir drehen das jetzt mal um und machen das ganz konkret. Wenn du in den drei schriftlichen Abschlussprüfungen von Teil 2 eine 6 hast oder zwei 5, dann bist du raus. Dann bestehst du deine Prüfung nicht und musst wiederholen.
[8:42] Andersherum heißt das, wenn du eine 5 hast, kannst du noch bestehen. Das ist völlig in Ordnung, solange die anderen Sachen eingehalten sind. Also wenn du eine 5 hast, mit den gesamten anderen Noten aus Teil 2, aber insgesamt auf 50% kommst, auf eine 4, ist das völlig okay. Und das ist ja relativ einfach, sagen wir einfach mal. Wenn wir mal gucken, die zählen ungefähr, ne, die zählen ungefähr alle gleich, die drei schriftlichen Prüfungen zählen alle 10% der Note. Das heißt, machen wir es mal ganz konkret. Du hast in Wieso 60 Prozent und in deiner ersten schriftlichen Prüfung, die berufsspezifisch ist, 50 Prozent. Und in deiner zweiten hast du leider nur 40 Prozent. Dann hast du trotzdem bestanden, weil 40 plus 60 plus 50 sind 150. Geteilt durch drei sind 50 Prozent. Das heißt, du hast insgesamt in Teil zwei eine Vier, ein Ausreichend, hast damit bestanden. Auch wenn du eine Fünf hast, diese 40 Prozent, die kannst du quasi ausgleichen durch die 60 Prozent in der anderen Prüfung. aufaddiert, geteilt durch 3. Wenn du dann auf 50% kommst, dann hast du bestanden. So, das ist jetzt auf der Audiospur schwer zu erklären mit der ganzen Rechnerei und das ist schwer zu folgen. Deswegen guck dir einfach die Online-Rechner an. Da gibt es einen Haufen von verschiedenen Websites, die solche Online-Prüfungsrechner für die IT-Berufe haben. Es gibt übrigens auch in Anführungszeichen offizielle Rechner von der IHK. Von einer der IHK, besser gesagt.
[9:58] Verlinke ich auch in den Shownotes zu dieser Episode. Das ist einfach eine Excel-Datei. Kannst du dir runterladen und da ist dann quasi die offizielle Berechnung, kannst dir auch angucken, wie das gerundet wird und so weiter. Manchmal kommt es ja wirklich auf die Nachkommastelle an, auf ein halbes Prozent, ob das dann auf- oder abgerundet wird, um die Prüfung zu bestehen. Von daher zieh dir einfach die Excel-Datei, trag dir mal deine Daten ein und dann weißt du, ob du bestehst oder nicht. Damit rechnet auch deine IHK.
[10:21] Gut, also wir fassen nochmal zusammen. Hast du eine 5, kannst du bestehen. Hast du zwei Fünfen oder eine 6 in den schriftlichen Prüfungen, dann bist du auf jeden Fall raus. So und jetzt kommen wir nochmal zurück zum Einleitungssatz von Absatz 2 in der Vorrufsordnung. Auch unter Berücksichtigung einer mündlichen Ergänzungsprüfung. Das heißt, wenn du jetzt zwei Fünfen hast oder eine 6, dann kannst du trotzdem noch bestehen, indem du diese Note durch die Ergänzungsprüfung ausgleichst. Darum geht es. Das heißt, bei zwei Fünfen müsstest du mit der Ergänzungsprüfung eine Fünf loswerden, also die auf eine Vier heben. Bei einer Sechs müsstest du mit einer MEP mindestens die Sechs auf die Fünf heben, damit du bestehst. Weil mit einer Fünf ist ja okay, kannst du bestehen, aber die Sechs darf halt nicht stehen bleiben. Das heißt, wann musst du in eine Ergänzungsprüfung? Ganz einfache Kiste. Hast du zwei Fünfen, musst du eine davon ausgleichen. Hast du eine Sechs, musst du die auf jeden Fall ausgleichen. Ja, und wenn du natürlich noch eine Sechs und eine Fünf hast, Ist ja gut, dann wird es irgendwann schwierig. Also du musst diese anderen Vorgaben einhalten. Insgesamt 50 Prozent in allen Prüfungsbereichen von Teil 2. Und wenn du das hinkriegst, dann hast du die Prüfung bestanden. Und ich sage mal schon so, eine 6 auszugleichen auf eine 4, auf 50 Prozent ist schon extrem schwierig. Wir machen mal ein kurzes Brechenbeispiel. Das werde ich gleich dann auch mal an ein, zwei Beispielen wiederholen.
[11:40] Wir haben nämlich noch gar nicht den Paragrafen uns angeschaut zur Münchner Ergänzungsprüfung, wie das berechnet wird. Aber ich spoiler schon mal so ein bisschen, wenn du eine 6 hast, also zum Beispiel 30 Prozent in einem Prüfungsteil, dann musst du tatsächlich 90 Prozent in der Ergänzungsprüfung holen, um diese 6 auf eine 4 hochzuziehen. Das ist also schon heftig. Ich meine, wenn du eine 6 hast, das ist ja, wie soll ich das sagen, da hast du echt nicht viel gewusst. Und es ist jetzt relativ unrealistisch, dann in der Ergänzungsprüfung zum gleichen Thema auf einmal 90%, also eine sehr gute 2 zu holen, um dann insgesamt auf eine 4 zu kommen. Also das ist schon unrealistisch. Deswegen geht es wahrscheinlich bei einer 6 eher darum, dass du die 6 auf eine 5 hebst, um dann halt damit deine Prüfung zu bestehen. Das ist zwar kein guter Abschluss, in Anführungszeichen, aber das Ding auf eine 4 zu heben ist in den meisten Fällen utopisch. Und das mit den 90% funktioniert ja nur, wenn du exakt 30% hast, wenn du weniger hast. Und ja, ich nehme das jetzt hier Anfang 2026 auf. Wir haben gerade die schriftlichen Prüfungen korrigiert letzte Woche. Da waren einige Sechsen leider dabei in einem schriftlichen Teil. Und das sind dann manchmal 15 Punkte, 16 Punkte. Da ist es dann rein rechnerisch schon gar nicht mehr möglich, auf eine 4 zu kommen überhaupt.
[12:54] Das heißt, das funktioniert bis, ja, müsste ich jetzt mal im Kopf rechnen, ich glaube bis 25 Punkten. Wenn du 25 Punkte hast, also eine dicke 6, und dann 100% in die Ergänzungsprüfung holst, dann kommst du auf die 50%, aber das ist ja unrealistisch, schon 25 auf 100, ganz ehrlich. Also von daher, da geht es dann meistens darum, auf eine 5 zu kommen, um gerade so mit einem Auge durch die Prüfung zu kommen quasi. Und wenn du zwei 5 hast, dann musst du aber wirklich eine davon auf eine 4 heben, weil du darfst das halt nur eine 5 haben. So, das ist jetzt mal zur Einleitung mit ein bisschen Beispielen und Rechnerei und jetzt gucken wir uns mal die Paragraphen zur Ergänzungsprüfung an, was da so drin steht.
[13:34] So, in der Vieh-Ausbüffe ist direkt der nächste Paragraf, der Paragraf 17 der zur mündlichen Ergänzungsprüfung. Und der geht los mit dem ersten Absatz. Der Prüfling kann in einem Prüfungsbereich eine mündliche Ergänzungsprüfung beantragen. Das heißt, erster Punkt, der Prüfling ist selbst dafür verantwortlich, diese MEP zu beantragen. Man kriegt die nicht automatisch. So steht es im Gesetz. Wie es in der Realität läuft, ist natürlich eine andere Frage. Die meisten IHK werden automatisch, wenn man ein schlechtes Ergebnis hat, eine MEP ansetzen, weil die Leute wollen ja durch die Prüfung kommen und wenn das jetzt jeder einzeln beantragen müsste und die Leute vergessen das, dann sind sie durchgefallen, müssen ein halbes Jahr. Also die meisten IHK werden das wahrscheinlich von sich aus regeln, aber rein rechtlich müsstest du selbst diese Ergänzungsprüfung beantragen. Jetzt kommt Nummer zwei.
[14:20] Dem Antrag ist stattzugeben, wenn er für einen der folgenden Prüfungsbereiche gestellt worden ist. A. Und jetzt kommen die fachspezifischen Namen der Prüfung. Ich bin jetzt hier im Bereich Anwendungsentwicklung, also Planen eines Softwareprodukts. B. Entwicklung und Umsetzung von Algorithmen. Oder C. Wirtschaft und Sozialkunde. So, und hier würden jetzt halt in den anderen Paragraphen die Namen deiner jeweiligen Prüfungsteile stehen, wenn du nicht Anwendungsentwicklung wärst. Und hier siehst du schon, es muss also in einem der schriftlichen Prüfungen sein. Du kannst nicht das Projekt ausgleichen. Das ist nicht möglich. Projekt durch, dann bist du leider durch. Das ist so. Also da gibt es keine MEP. Nur in einer der drei schriftlichen Prüfungen kannst du eine MEP machen. Jetzt kommt Satz 2. Wenn der benannte Prüfungsbereich schlechter als mit ausreichend bewertet worden ist. Das heißt, auf Deutsch gesagt, du musst durchgefallen sein. Du musst unter 50 Prozent haben.
[15:12] Du kannst also mit einer MEP nicht deine Note aufbessern. Angenommen, du hast jetzt, weiß ich nicht, eine 4 oder eine 3 und willst aber eine 1. Das geht leider nicht. Also die MEP ist nur dafür da, deine Prüfung zu bestehen, wenn du eigentlich durchgefallen wärst. Du kannst sie nicht noch einfach mal munter beantragen, um deine Note hochzuziehen oder so, weil du Lust hast. Das funktioniert nicht. Es geht hier nur ums Bestehen oder nicht. Und Nummer drei, das ist auch nochmal wichtig, wenn die mündliche Ergänzungsprüfung für das Bestehen der Abschlussprüfung den Ausschlag geben kann. Auf Deutsch gesagt, du darfst nur eine MEP machen, wenn du danach auch die Prüfung bestehen kannst. Wenn du zum Beispiel schon drei Fünfen hast oder eine Fünf und eine Sechs oder so und es ist rein rechnerisch gar nicht mehr möglich, die Prüfung zu bestehen, dann wird dich auch keiner eine mündliche Ergänzungsprüfung machen lassen. Das ist ja vergebene Liebesmüh für dich und auch für den Prüfungsausschuss. Die prüfen dann irgendwas und am Ende bist du trotzdem durchgefallen. Also das wird nicht passieren. Das heißt, du darfst nur in einer der schriftlichen drei Prüfungen eine MEP beantragen, auch nur, wenn du da durchgefallen bist, also unter 50 Prozent hast, und auch nur, wenn du dann im Endergebnis noch bestehen kannst. Und wenn das nicht mehr möglich ist, gibt es auch keine MEP. Ganz einfach.
[16:19] So, jetzt kommt der nächste Punkt. Die mündliche Ergänzungsprüfung darf nur in einem einzigen Prüfungsbereich durchgeführt werden. Das heißt, wenn du durch drei Prüfungen durchfällst, kannst du nicht drei MEPs machen und bist dann trotzdem durch. Dann ist durchgefallen wirklich durchgefallen. Sondern du kannst eine einzige Ergänzungsprüfung machen, um eine 6 oder eine 5 hochzuziehen oder auszugleichen. Wenn du mehrere Probleme hast, dann kannst du dich schon auf einstellen, in einem halben Jahr nochmal die Prüfung zu machen. Da hast du keine Chance. Du kannst jetzt nicht nochmal drei MEPs machen, weil du alle 5 hast. Das funktioniert leider nicht. Eine einzige MEP ist möglich. Dann kommt Absatz 3, die mündliche Ergänzungsprüfung soll 15 Minuten dauern. Also quasi wie das Fachgespräch. Präsentation, Fachgespräch, MEP dauern alle 15 Minuten. Hier steht, soll 15 Minuten dauern.
[17:06] Kann auch mal 16 dauern oder 14, je nachdem, aber 15 ist das Richtmaß. Und dann kommt 4, bei der Ermittlung des Ergebnisses für den Prüfungsbereich sind das bisherige Ergebnis und das Ergebnis der mündlichen Ergänzungsprüfung im Verhältnis 2 zu 1 zu gewichten. Was bedeutet das? Da sehen wir jetzt, dass so eine MEP gar nicht so viel Hebelwirkung hat, denn dein bisheriges Ergebnis wird mal 2 genommen und das Ergebnis der MEP wird mal 1 genommen und das wird dann geteilt durch 3 dein neues Ergebnis. Beispiel von eben, wenn du 40% geschrieben hast, also eine 5, dann wird das mal 2 genommen, also 80 und dann kommt deine Ergänzungsprüfung dazu, angenommen du hast da 50% geholt, dann wird gerechnet 80 plus die 50, das sind 130 und jetzt müssen wir aber nochmal durch 3 teilen, um auf eine Note zu kommen und 130 durch 3 sind leider weniger als 50, das heißt du bist im Endergebnis trotzdem durchgefallen. Wie können wir jetzt ausrechnen, was du haben musst, damit du bestehst? Bleiben wir bei den 40%. Die 40%, die du geschrieben hast, wird verdoppelt, also 80. Und jetzt kann man ja ein bisschen mathematisch überlegen. Wenn am Ende das Ding geteilt durch 3 gerechnet wird und du dann auf 50% kommen musst, dann wäre ja das Minimum, was du erreichen musst, durch zweimal altes Ergebnis plus einmal neues, 150. Weil 150 geteilt durch 3 ist 50%, dann hättest du bestanden.
[18:32] Jetzt können wir das also einfach ein bisschen umstellen und ein bisschen rechnen. Wenn du 40 Prozent hast, nimmst du das Ding mal 2, sind die 80. Und jetzt musst du eigentlich nur noch die Differenz bis 150 erreichen. Das wäre 150 minus 80 sind 70. Das heißt, wenn du 40 geschrieben hast, musst du 70 Prozent in der MEP holen, damit du insgesamt auf 50 Prozent und damit auf das Bestehen kommst. Und du siehst schon, das ist ganz schön viel. 40 ist, naja, eine mittlere 5, ziemlich genau die Mitte der 5. Und jetzt musst du aber 70 Prozent, also eine, naja, schlechte 3 in der MEP holen, um das auszugleichen. Und von 5 auf 3, ich meine, das sind zwei Noten dazwischen. Das ist jetzt also nicht so einfach. Man kann jetzt also nicht sagen, ja, ich mache mal eben eine MEP und dann rette ich mir den Arsch. Auf Deutsch gesagt, du musst da ganz schön viele Punkte holen aufgrund dieses Verhältnisses, aufgrund der Gewichtung. Und deswegen mein Beispiel von vorhin, wenn du eine 6 hast, 30 Prozent, 30 mal 2 sind 60, 150 minus 60. Sind 90%. Das heißt, du musst eine gute 2 holen, um eine 6 ausgleichen zu können.
[19:38] Wenn wir das jetzt mal umdrehen und ein bisschen rechnen, wenn wir mal 2 nehmen und wir fangen mit 25% an, weil du eine gute 6 hast mit 25%, die geht da bis 0, dann hast du 25 mal 2 sind 50 und 150 minus 50 sind 100. Das heißt, das wäre das Maximum, wenn du in einer MEP 100% holst, also perfekt die MEP machst, dann kannst du maximal 25 Punkte in einer Prüfung ausgleichen. Anders formuliert, ab 24 Punkten ist vorbei. Wenn du 24 Punkte oder schlechter in einem dieser drei schriftlichen Prüfungen hast, dann kannst du nicht mehr auf 50% in dieser Prüfung kommen. Es ist nicht mehr möglich. Rein rechnerisch geht das nicht.
[20:21] Und wie gesagt, ich habe jetzt gerade schon erzählt, wir haben ein paar mehr Prüfungen dieses Jahr, die unter 24 Punkten waren, auf jeden Fall. Und da kann es dann wirklich nur noch darum gehen, aus der 6 eine 5 zu machen. Alles andere ist nicht realistisch. Und dann kann man nur die Daumen drücken, dass nicht in dem anderen Prüfungsteil noch irgendwo eine 5 da steht, weil sonst ist es halt vorbei. Das heißt, wenn man eine 6 hat und in den anderen Teilen eine 4 oder besser, dann kriegt man es noch hin, indem man die auf eine 5 hebt. Aber ansonsten ist man mit einer 6 leider raus, weil du es rechnerisch einfach nicht ausgleichen kannst. Funktioniert nicht.
[20:52] Also, es ist nicht immer das Ziel, in einer mündlichen Ergänzungsprüfung für diesen Prüfungsbereich auf 50 Prozent zu kommen, also auf eine 4, sondern es geht meistens darum, wenn man wirklich schlechte Prüfungen hat, dass man insgesamt noch auf diese 50 Prozent für alle Prüfungsbereiche kommt und nur eine 5 da stehen hat. Das ist eigentlich das Ziel, was viele Prüflinge haben werden. Es geht hier also nicht darum, oh, ich mache nochmal eben die MEB und am Ende habe ich doch noch eine 1. Na, nee. Allein durch diesen letzten Satz, die Nummer 4 in dem Paragrafen hier, das Verhältnis 2 zu 1, ist es rechnerisch unmöglich, auf eine wirklich gute Note noch zu kommen mit der MEP. Es funktioniert einfach nicht. Also, wir fassen nochmal zusammen. Du musst die MEP selbst beantragen. In der Realität wird deine IHK das aber sehr wahrscheinlich automatisch für dich machen. Es darf nur in einem der schriftlichen Prüfungsteile passieren. Diese Prüfung muss schlechter als 4 sein, also ab 49 abwärts. Und du darfst auch nur die MEP machen, wenn du insgesamt noch bestehen kannst. Und wir haben ja gerade schon ein paar Beispiele gesehen, dass das teilweise recht schwierig ist. Also in dem Fall kannst du dich eigentlich davon verabschieden, wenn du zwei Fünfen hast und nicht mehr ausgleichen kannst oder so eine schlechte Sechs. Dann musst du leider die Prüfung wiederholen in einem halben Jahr. Das geht nicht anders. Die mögliche Ergänzungsprüfung dauert 15 Minuten und Gewichtung ist 2 zu 1. So ein paar Berechnungsbeispiele hatten wir jetzt. Dürfte die formale Geschichte, sag ich mal, klar sein. Und jetzt kommen wir zum nächsten Teil.
[22:15] Und zwar stellen sich natürlich viele Prüflinge, die in eine MEP müssen, die Frage, oh Gott, wie läuft das denn ab? Gibt es einen separaten Termin? Wird das einfach nach der Prüfung gemacht? Etc. Und da kann ich leider nur die Antwort geben. Kommt drauf an. Und worauf kommt es an? Naja, auf eine der 79 IHK, bei der du geprüft wirst, weil das ist nicht geregelt. Ich habe jetzt alles aus dem Gesetz, aus der Berufsverordnung vorgelesen zur MEP. Hier steht also nirgends mehr drin, es ist am Tag der möglichen Prüfung durchzuführen oder Sonstiges. Es gibt keine weiteren Vorgaben. Das heißt, es liegt jetzt einfach an deiner IHK, wann und wo und wie du geprüft wirst.
[22:52] Es soll eine mündliche Prüfung sein von 15 Minuten. Das ist der einzige Teil, der vorgegeben ist. In unserem Fall, ich kann es von mir berichten, von IHK Hollenburg, wir machen es so, dass wir die MEPen, das ist ja eingeschränkt auf eine einzige, man kann ja nur eine einzige MEP machen, wie gerade vorgelesen. Und deswegen machen wir die immer direkt am Prüfungstag, wo der Prüfling auch vor Ort ist. In unserem Fall, wir haben ein großes Einzugsgebiet, da fahren die Leute teilweise eine Stunde, teilweise anderthalb Stunden bis zur Prüfung. Und wenn man da jetzt noch einen zweiten Termin macht, wo man nur für 15 Minuten herfahren muss. Das ist sowohl für den Prüfling, allerdings auch für den Prüfungsausschuss extrem nervig, weil wir kommen auch nicht alle aus Oldenburg selber und fahren teilweise ich selber zum Beispiel auch über eine Stunde zur Prüfung. Und das ist ja alles Ehrenamt und Freizeit, beziehungsweise geht bei den meisten Leuten von der Arbeitszeit ab und die Arbeitgeber stellen frei. Das heißt, da wollen wir nicht nochmal für 15 Minuten für eine Person irgendwo hinfahren. Das ist einfach viel zu aufwendig. Deswegen machen wir das einfach am gleichen Tag. Ich weiß aber, dass es bei anderen IHKern durchaus einen separaten Termin nur für Ergänzungsprüfung gibt. Also kurz gesagt wieder mal, es kommt drauf an. Frag bei deiner IHK, wie es da geregelt ist. Einige IHKern schicken dann sogar Einladungen raus, wo drin steht, hier und da und dort ist die Ergänzungsprüfung.
[24:04] Das ist wirklich ganz, ganz unterschiedlich. Und bitte verlass dich da weder auf meine Aussagen noch auf irgendwas anderes im Internet oder bei Reddit oder sonst wo. Frag bei deiner IHK nach. Das ist das einzige Verlässliche für deine Prüfung. Niemand anderes aus dem Internet kann dir da weiterhelfen. Und selbst wenn du einen Prüfling hast, der bei deiner IHK geprüft wurde, vielleicht ist das inzwischen verändert worden. Vielleicht macht der eine Ausschuss das so und der andere Ausschuss das so. Wir haben zum Beispiel in Oldenburg drei verschiedene Ausschüsse, die arbeiten weder am gleichen Standort noch nach exakt den gleichen Vorgaben im gleichen Raum etc. Das heißt, es kann von Ausschuss zu Ausschuss sogar noch unterschiedlich sein. Also bitte, bitte, bitte, frag bei deiner IHK nach und verlass dich nicht auf irgendwas anderes, was du sonst wo gelesen hast. Außer auf der offiziellen Seite deiner IHK. Wenn du da was liest, kannst du davon ausgehen, dass das stimmt.
[24:50] Okay, also kurz gesagt, wann und wo die stattfindet, kommt darauf an. In unserem Fall ist es so, dass wir es einfach nach den restlichen Prüfungen am Tag der mündlichen Prüfung machen, also nach Präsentation im Fachgespräch. Dann geht in unserem Fall der Prüfung nochmal einmal raus. Wir überlegen uns Fragen für die mündliche Ergänzungsprüfung und dann kommt der Prüfung wieder rein und dann geht er bloß. Die letzte MEP, die ich hatte, war tatsächlich im Bereich WISO. Da haben wir uns einige alte WISO-Prüfungen geschnappt, haben ein paar Themenbereiche rausgesucht und haben darüber halt ein zweites Fachgespräch geführt, wenn man so will. Und das war dann unsere MEP. Auch das kann von IHK zu IHK und von Ausschuss zu Ausschuss komplett unterschiedlich sein. Ich habe schon gehört von Ausschüssen, die erstmal schriftliche Aufgaben dem Prüfling geben, die er in Ruhe vorbereiten kann und dann wird darüber ein Fachgespräch geführt. Ich habe schon gehört von Aufgaben, die man an einer Tafel lösen musste. Sowas wie formulieren Sie ein SQL-Statement oder machen Sie dies und das im Pseudocode und dann an der Tafel. Also es gibt da ganz, ganz unterschiedliche Ausprägungen. Auch das kann ich dir nicht verbindlich für deine IHK und deinen Ausschuss sagen. Wenn die IHK dir das erzählt, wie das geht, dann ruf da an und frag nach. Aber im Zweifel wissen die das noch nicht mal, weil die Ausschüsse das unterschiedlich machen. Du musst immer daran denken, die IHK ist das Verwaltungsorgan, kümmert sich um die Termine und Einladungen und alles. Aber der Prüfungsausschuss, der bestimmt deine Note, der prüft dich. Und der hat im Prinzip die Freiheit, diese Prüfung zu gestalten, wie er möchte. Denn, wie wir gerade gesehen haben, im Gesetz ist da nichts vorgegeben, außer 15 Minuten unmündlich.
[26:15] Okay, also auch hier, da kannst du dich dann vielleicht an Erfahrungsberichten von anderen Prüflingen orientieren, vielleicht im Internet irgendwo mal gucken, im Forum, bei Reddit etc., ob irgendwer von deiner IHK schon mal eine MEP hatte. Und dann kannst du da fragen, wie es abgelaufen ist. Aber auch hier, bevor du im Internet einen Thread aufmachst, ruf doch mal bei der IHK an oder schick eine E-Mail hin. Denn die wissen wohl mit einer MEP, dass man da vielleicht ein bisschen nervös wird und tausend Fragen hat. Und da sollten die dann darauf reagieren und antworten. Dann als, weiß ich nicht, Ausbildungsberaterinnen gibt es dann, glaube ich, bei der IHK, die helfen dir dann.
[26:47] Die sind dafür zuständig. Das heißt, wenn du verlässliche Informationen zu deiner MEP haben willst, bitte, ich wiederhole es nochmal, weil ich sehe so viele Beiträge im Internet, wo du dann fragen, wie ist das dann bei der IHK XY, wie werde ich denn da geprüft? Ja, weiß ich nicht, keine Ahnung. Frag doch bitte bei der IHK nach. Wie gesagt, 79 verschiedene, alle machen es unterschiedlich. Also einmal anrufen, Hörer in der Hand nehmen oder Handy in der Hand nehmen, Hörer gibt es ja gar nicht mehr und ruf da mal an und frag mal nach. Also, in unserem Fall ist es dann so, Prüfling kommt rein, es wird rein mündlich gemacht, wir bereiten nichts vor, wir lassen die Leute auch nichts an der Tafel schreiben und es ist eine rein mündliche Prüfung quasi wie das Fachgespräch, nur eben, und das ist jetzt ganz wichtig, zu Themen aus dem Prüfungsbereich, wo der Prüfling eben durchgefallen ist. Das heißt zum Beispiel Wieso, habe ich gerade gesagt, dann stellen wir halt Fragen zu Mutterschutzgesetz oder zu Tarifverhandlungen oder zu Streikrecht oder weiß ich nicht, Jugendarbeitsschutzgesetz und was da alles halt drankommt in Wieso. Das kann jetzt halt von A nach B, können wir uns da irgendwas ausdenken, es muss halt zu diesem Prüfungsbereich passen. Oder wenn es zum Beispiel Entwicklung von Algorithmen ist, dann fragen wir irgendwas zu Pseudocode oder zu SQL oder zu irgendwelchen Ur-Mail-Diagrammen oder so etwas. Das muss halt zu dem Prüfungsbereich passen. Aus diesem Bereich kommen die Fragen. Und das wäre jetzt auch der letzte Punkt für heute. Wie bereite ich mich auf die MEP vor? Ja, quasi genauso wie auf den jeweiligen Prüfungsbereich, wo du durchgefallen bist. Das ist jetzt ein toller Tipp, weil du bist ja da durchgefallen. Also hat das offensichtlich nicht so gut funktioniert mit der Vorbereitung.
[28:13] Manchmal liegt es aber auch einfach an Zeitdruck in der Prüfung. Man schafft die Aufgaben nicht mehr und so weiter. Und deswegen ist es dann vielleicht für eine mündliche Ergänzungsprüfung gar nicht mal so schwierig, weil man kann sich da ein bisschen mehr Zeit lassen. Es ist mündlich, man kann umschreiben. Ja, man muss nicht auf den Punkt präzise, zack, auf den Text in drei Zeilen exakt genau das beschreiben. Das heißt, vielleicht fällt es dir einfach einfacher, so eine mündliche Ergänzungsprüfung zu machen, als es auf dem Papier zu machen. Aber falls das nicht der Fall ist und du dich einfach nur schlecht vorbereitet hast oder große Wissenslücken hast, dann wird es natürlich interessant. Dann musst du einfach die Themen nochmal nacharbeiten, die du dir schon für die schriftliche Prüfung hättest anschauen müssen. Ganz einfach. Und da kann ich dann nur empfehlen, guck dir die alten schriftlichen Prüfungen an. Inzwischen, wir sind im Jahr 2026, wo ich das hier aufnehme, gibt es elf oder zwölf alte Prüfungen und die kannst du rauf und runter dir durchschauen. Auf meiner Website habe ich noch eine große Liste mit bisherigen Themen in den schriftlichen Abschlussprüfungen, zumindest für Einwilligungsentwicklung, für die anderen Fachbereiche leider nicht. Aber du könntest dir die Prüfung einfach selber durchgucken. Und schauen, was kommen denn da so für Themen dran. Und darauf musst du dich vorbereiten. Und in diesem Fall dann eben nicht so, dass du sie schriftlich auf Papier bringst, sondern eben mündlich. Das heißt, du übst, wie du das formulierst.
[29:23] Vielleicht in unserem Beispiel jetzt SQL. Versuchst du mündlich mal SQL-Abfragen zu formulieren, ja? Falls du das so geprüft wirst. Wie gesagt, bei deiner IHK kann das halt anders laufen. Du musst es vielleicht doch noch auf Papier machen, ja? Aber im Kern ist es ja eine mündliche Prüfung. Das heißt, du musst üben, wie du diese Inhalte auf der Audiospur vernünftig und verständlich erklärst. Also im Prinzip von der Prüfungsart bereitest du dich genauso vor wie auf dem Fachgespräch. Von den Inhalten bereitest du dich so vor wie das, was in der schriftlichen Prüfung drankommt, wo du durchgefallen bist. Und im besten Fall hilft natürlich Ausbilder, Ausbilderinnen dabei, dass ihr sowas einfach mal simuliert. Also, was für Fragen könnten denn gestellt werden zum Thema SQL oder zum Thema, weiß ich nicht, Firewall, Netzplan, Wieso, wie gesagt, Mutterschutzgesetz oder was auch immer, ja, dann spiel das einfach mal durch. Das heißt, Vorbereitung würde ich genauso empfehlen wie das Fachgespräch mit einer anderen Person wirklich mal zu sprechen. Im besten Fall mit einer Person, die sich auskennt und die sagen kann, ob das richtig war oder nicht. Also, Ausbilder, Ausbilderin, dafür sind die ja da. Das ist ja eigentlich deren Job, das zu tun, ja. Und inhaltlich, wie gesagt, guck die alten Prüfungen durch, such dir ein, zwei Themen raus und sprich das dann einfach mal mit Ausbilder-Ausbauern durch.
[30:33] Früher war es so, vor der Neuordnung, dass der Prüfling sogar sich selber aussuchen konnte, in welchem Bereich man geprüft wird, also in welchem Themenbereich. Man konnte das also zum Beispiel runterdampfen auf Softwareentwicklung oder Datenbanken oder so etwas. Das ist inzwischen aber nicht mehr möglich. Inzwischen ist einfach das Thema der durchgefallenen Prüfung das Thema der MEP. Das heißt, genauso breit, wie die schriftliche Prüfung ist, ist das Themenfeld für die mündliche Ergänzungsprüfung. Du musst dich also auf alles vorbereiten. Du kannst nicht sagen, ach ja, ich bin in dem Teil durchgefahren, da werden die ja mich bestimmt SQL fragen. Nee, die Prüfer und Prüferinnen können sich halt selber aussuchen, was sie aus diesem Themengebiet abfragen. Das ist genauso wie in der schriftlichen Prüfung, da hast du auch keinen Einfluss drauf. Dann machst du den Umschlag auf und wunderst dich, oh, das kam dran, ja, super. Und genauso ist es in der MEP auch. Also bereite dich auf alle Themen vor, guck die alte Prüfung an und üb das Zeug auf der Audiospur mit Ausbilder, Ausbilderin, Lehrer, Lehrerin, wem auch immer, irgendein fertiger Azubi-Kollege, wenn du keine Ausbilder, Ausbilderin hast. Aber irgendwie bereite dich am besten darauf vor, dass du das mündlicher machen musst. Das ist durchaus was anderes. Ein Beispiel jetzt hier mal Use-Case-Diagramm der UML auf dem Papier zu zeichnen, oder auf der Audiospur zu erklären, wie du es zeichnen würdest. Ja, das ist ein bisschen was anderes.
[31:48] Würde ich jetzt als Prüfender ein UML-Use-Case-Diagramm in der möglichen Prüfung abfragen? Eher nicht, weil es ist ja halt eben ein visuelles Ding. Aber man könnte vielleicht sowas fragen wie, was ist denn überhaupt ein Use-Case-Diagramm? Und was ist denn ein Akteur? Oder wie würde der denn aussehen? Oder was ist denn überhaupt ein Use-Case? Solche Sachen könnte man fragen. Aber so nach dem Motto, zeichnen Sie mir mal hier in Ihren Gedanken ein Use-Case-Diagramm. Solche Aufgaben finde ich persönlich natürlich maximal dämlich. Das heißt aber nicht, dass irgendwelche anderen Prüfungsausschüsse das nicht genau so machen. Oder wie eben erklärt, das dann einfach an der Tafel machen lassen. Ist ja auch okay. Also, da sind die Prüfungsausschüsse völlig autonom und können sich selber ausdenken, wie sie diese Prüfung gestalten. Also, wenn du was zeichnen musst, ist das so. Da kannst du dich auch nicht beschweren oder sonst irgendwas, weil, wie gesagt, die einzige Vorgabe ist, mündlich und 15 Minuten.
[32:33] So, fassen wir nochmal zusammen. Du bereitest dich vor mit alten Prüfungen. Du bereitest dich aber so vor, dass du es mündlich vortragen kannst. Am besten mit einer anderen Person zusammen, Ausbilder, Ausbilderin. Und ja, dann war es das eigentlich. Bereit dich auf alle Themen vor, die in diesem jeweiligen Prüfungsteil drankommen können.
[32:51] So, jetzt haben wir glaube ich alles. Zu MEP. Fassen wir nochmal kurz zusammen. Die MEP musst du machen, wenn du zwei Fünfen oder eine Sechs hast. Du musst sie nutzen, um insgesamt in Teil 2 auf 50% zu kommen. Meistens ist das nicht möglich, zum Beispiel eine Sechs auszugleichen, sondern einfach nur auf eine Fünf zu kommen, damit du insgesamt auf die 50% kommst. Es geht hier nicht darum, irgendwelche aus deiner Sicht schlechten Prüfungsteile zu verbessern, sondern es geht nur, wenn du da auch wirklich durchgefallen bist. Und es gibt eine einzige Ergänzungsprüfung. Wenn du damit deine Note nicht ausgleichen kannst, dann bist du durchgefallen und musst leider in einem halben Jahr nochmal ran. Eine andere Möglichkeit gibt es nicht. Wann die durchgeführt wird, wo und wie, das ist völlig unterschiedlich, je nach IHK. Deswegen frag da vor Ort nach, wie das bei dir vielleicht ablaufen wird, ob du selber den Antrag stellen musst, ob die IHK das schon für dich macht. Das sind wichtige Fragen, die du dir stellen musst. Denn wenn du am Ende es beantragen hättest müssen und vergisst es und fällst deswegen durch, das wäre natürlich extrem schade. Also kümmere dich rechtzeitig, sobald du siehst, oh, meine Noten, da komme ich aber nicht mehr auf die 50. Dann ist das Erste, was du machen musst, anrufen bei deiner IHK und fragen, wie geht es jetzt weiter, was muss ich machen. Verlasse dich nicht darauf, dass das alles schon irgendwie automatisch man sich um dich kümmern wird, sondern werde selber aktiv, frag nach, was du machen musst und verlass dich nicht auf irgendwelche random Aussagen aus dem Internet, sondern frag bei deiner IHK nach. Ich kann es jetzt nur noch mal wiederholen, weil das so wichtig ist.
[34:21] Ruf da an, frag nach oder schick eine E-Mail, wenn du dich anrufen willst. Aber kümmere dich bei deiner IHK darum und nicht irgendwo anders im Internet. So, und dann ist ansonsten die mündliche Ergänzungsprüfung aus meiner Sicht aber recht entspannt, weil die Prüfenden, wie die dir da gegenüber sitzen, die wollen ja auch dein Bestes. Ich meine, die MEP ist dafür da, damit du gerade noch die Prüfung bestehen kannst und das wollen die Prüfenden auch. Die Prüfenden haben keinerlei Interesse daran, dich absichtlich durchfallen zu lassen, damit du im halben Jahr nochmal geprüft werden musst. Wir müssen die ganzen Prüfungen ja dann nochmal korrigieren und wir müssen dich nochmal zum Fachgespräch einladen etc. Also wir haben da ja auch nichts davon. Im Gegenteil. Das heißt, die Prüfenden wollen auch, dass du bestehst und wollen dir helfen.
[35:01] Etwas bessere Noten als die fünf oder sechs, die man geschrieben hat, hat durchaus realistisch. Im mündlichen kann man halt viel mehr umschreiben und irgendwo nochmal Punkte geben, als wenn man das hart auf Papier aufgeschrieben hat. Ja, das heißt, die Prüfenden sind ein bisschen nachsichtiger und werden dir sicherlich vielleicht auch nicht die allerhärtesten Fragen stellen, sondern halt so in die Richtung, dass du noch eine Chance hast, durch die Prüfung zu kommen. Davon musst du einfach mal ausgehen. Und wenn du einen Prüfungsausschuss hast, der es tatsächlich darauf anlegt, dich durchfallen zu lassen, okay, dann hast du Pech gehabt, aber dann sollten das vielleicht auch keine Prüfenden sein. Ja, die meisten Prüfenden sind pro Prüfling eingestellt und wollen dir helfen. Und ich glaube, es gibt eigentlich keinen Prüfungsbereich, wo das besser geht als in der mündlichen Prüfung. Weil da kann man mit geschickten Fragen und so weiter, kann man da schon den Prüfling auch mehr unterstützen, als wenn man, ja, wie gesagt, leeres Blatt Papier, da kann ich halt nur sechs draufschreiben. Aber mit ein bisschen Nachfragen im mündlichen Bereich kriegen wir dich schon in die richtige Richtung, sodass du die Prüfung bestehst. Ja, also mach dir da nicht zu viel Gedanken. Die Prüfenden sind normalerweise alle sehr nett und wollen dir helfen und wollen dich unterstützen.
[36:04] Du musst dich natürlich aber auch ein bisschen darauf vorbereiten. Es ist deine letzte Chance, die Prüfung noch zu bestehen. Das müsstest du keine machen. Also setz dich nochmal hin, reiß dir den Hintern auf, guck dir alle Themen nochmal an, üb das Ganze mit einer anderen Person, damit du da gut dastehst in der MEP. Und dann ist es auch durchaus realistisch, dass du mit der MEP deine Prüfung noch bestehst. Ja, das will ich da sagen. Also, wenn du in die MBP gehst, heißt das nicht automatisch, dass du es nicht mehr schaffen kannst, sonst würde die MBP gar nicht angeboten, sondern geh davon aus, dass man dir helfen will, die Prüfung noch zu bestehen, aber tu auch was dafür. Ja, das will ich damit sagen.
[36:38] So, jetzt haben wir heute alles, glaube ich. Ich denke, das war ein guter Refresher, ein gutes Upgrade für dieses häufig nachgefragte Thema der mündlichen Ergänzungsprüfung. Ich hoffe, es war für dich dabei. Falls du den MBP musst, ich drücke dir beide Daumen, dass du damit trotzdem noch deine Prüfung bestehst. Und ja, wenn ich dir geholfen habe, dann lass mir gerne einen Kommentar da, am besten direkt unter der Episode. Da freue ich mich auf dein Feedback. Und jetzt alles Gute für die Prüfung. Mach’s gut und bis zum nächsten Mal.
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.
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.
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.
In der Projektpräsentation solltest du nur dann auf einen Fehler eingehen, wenn er für die gezeigten Inhalte relevant ist.
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.
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
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.
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.
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.
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
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
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.
[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.
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.
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.
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.
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.
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.
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.
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.
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.
[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.
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.
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.
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 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.
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.
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.
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.
[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.
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
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.
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.
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
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.
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.
Anforderungsermittlung
Lastenheft
Pflichtenheft
User Storys
Product Backlog
Architekturskizzen
UML-Diagramme
Klassendiagramme
Sequenzdiagramme
Zustandsdiagramme
Komponentendiagramme
Deployment-Diagramme
Netzwerkpläne
Server-Erreichbarkeit
Ports und technische Zusammenhänge
ER-Modelle
relationale Tabellenmodelle
JSON-Strukturen
OpenAPI-Beschreibungen bei REST-APIs
dokumentierte oder optimierte Prozesse
Modellierung mit BPMN
EPK
Aktivitätsdiagramme
Quellcode aus Produktivcode oder Testcode
Screenshots
Konfigurationsdateien
Fotos von umgesetzten Arbeiten
Vorgehensmodell wie Scrum, Wasserfall oder Kanban
Beschreibung des Entwicklungsprozesses
Ticket-System
Code-Review
Zusammenarbeit mit anderen Beteiligten
organisatorische Abläufe
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.
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.
[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!
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.
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.
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.
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.
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
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
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.
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.
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.
Wenn Software international eingesetzt wird, entstehen Anforderungen durch Sprache und Nutzungskontext, zum Beispiel:
Übersetzungen
unterschiedliche Schreibrichtungen
Datumsformate
Zahlenformate
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
Wenn externe Unternehmen beteiligt sind, können zusätzliche Anforderungen entstehen, etwa:
technische oder organisatorische Schnittstellen
Kommunikationswege
Service-Level-Agreements
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.
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.
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.
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.
[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.
Wenn eine VM im Cluster Ressourcen belegt, können diese Ressourcen nicht für andere VMs genutzt werden.
Auch wenn diese Ressourcen schon vorhanden sind, entstehen deinem Projekt dadurch also reale Kosten.
Ich erkläre, dass Kosten nicht zufällig bei einem einzelnen Projekt landen dürfen. Wenn mehrere Projekte dieselbe Infrastruktur nutzen, sollten die Kosten fair verteilt werden.
Beispiel:
Wenn auf einem Server bereits zehn Projekte laufen und durch das elfte ein neuer Server nötig wird, darf nicht nur dieses elfte Projekt die gesamten Kosten tragen.
Stattdessen müssen die Kosten anteilig auf alle Projekte umgelegt werden, die diese Ressource nutzen.
Das gilt auch für:
Server
VMs
Lizenzen
Arbeitszeit von Kolleg:innen
andere gemeinsam genutzte Ressourcen
Ich empfehle dir, diese Kosten möglichst nicht selbst bis ins kleinste Detail auszurechnen. Besser ist es, dir Werte aus dem Unternehmen geben zu lassen, zum Beispiel von:
Personalabteilung
IT-Betrieb
Rechnungswesen
Buchhaltung
Controlling
Sinnvoll sind zum Beispiel:
Stundensätze für Mitarbeiter:innen
Pauschalen für VMs oder Serverbetrieb
Gemeinkostensätze
anteilig umgelegte Lizenzkosten
So zeigst du, dass du an die Kosten gedacht hast, ohne unnötige Rechenfehler einzubauen.
Ein weiterer häufiger Fehler ist, nur die einmaligen Projektkosten zu betrachten. Ich mache deutlich, dass IT-Projekte fast immer auch laufende Kosten verursachen.
Dazu gehören zum Beispiel:
Stromkosten
Wartung
Updates
Lizenzkosten
Cloud-Kosten
Support-Verträge
Betriebsaufwand durch Admins
Diese Kosten fallen auch nach Projektende weiter an. Wenn du sie nicht berücksichtigst, wird die Amortisationszeit zu kurz dargestellt und die Kalkulation unrealistisch.
Ich betone, dass eine längere Amortisationszeit nicht schlimm ist. Problematisch ist vielmehr, wenn laufende Kosten weggelassen werden. Dann scheint das Projekt wirtschaftlicher, als es tatsächlich ist. Auf Dauer würde ein Unternehmen Verluste machen, wenn solche laufenden Kosten bei allen Projekten ignoriert würden.
Mögliche Kosten können sein:
Server oder VM-Ressourcen
CPU, RAM und Storage
Backup-Systeme
Monitoring
Arbeitszeit von Admins für Einrichtung, Betrieb und Wartung
Mögliche Kosten können sein:
IDE-Lizenzen
weitere Software-Tools
Testsysteme oder Staging-Systeme
Datenbanken
CI/CD-Pipelines oder Build-Server
genutzte Infrastruktur-Ressourcen
Für andere IT-Berufe gilt sinngemäß dasselbe.
Ich würde dir empfehlen:
Erstelle zuerst eine Liste aller genutzten Ressourcen.
Prüfe dann, welche Kosten dafür im Unternehmen angesetzt werden.
Nutze möglichst Pauschalen, Stundensätze oder Gemeinkosten statt eigener Detailrechnungen.
Berücksichtige sowohl einmalige als auch laufende Kosten.
Lege gemeinsam genutzte Ressourcen bei Bedarf anteilig auf dein Projekt um.
Verwende diese Werte anschließend für eine realistische Amortisationsrechnung.
Meine Kernaussage ist: Nicht nur neue Anschaffungen verursachen Kosten, sondern auch alles, was bereits vorhanden ist und von deinem Projekt genutzt wird. Vorhandene Ressourcen sind nie kostenlos. Zusätzlich solltest du immer laufende Kosten mit einplanen. Wenn du das sauber machst, wirkt deine Kostenbetrachtung realistischer und vollständiger.
[0:20] Heute möchte ich mich mal mit einem Thema beschäftigen, was ich sehr häufig falsch in Anführungszeichen in Projektdokus und Präsentationen wähle. Und zwar das Thema der EDA-Kosten, beziehungsweise auch der laufenden Kosten. Und ich bringe noch ein Passwort mit rein, die Opportunitätskosten. Heute soll es also um die Kostenbetrachtung deines Abschlussprojekts gehen. Und wir haben da oft ein Problem, dass nicht alle Kosten betrachtet werden. Und dass das Projekt sich dann super schnell amortisiert oder halt viel zu geringe Kosten einfach hat, um das irgendwie realistisch einplanen zu können in so einem Unternehmen. Und deswegen will ich da heute einmal kurz darauf eingehen, was da häufig vergessen wird, was das überhaupt ist, was ich damit meine und wie man das dann besser machen könnte. Also Nummer eins, es geht darum, bei deiner Projektarbeit dein Projekt auch realistisch einzuschätzen, was die Kosten angeht. Du sollst ja nicht einfach sagen, ja, ich habe da 80 Stunden als Zubi daran gesessen. Ich bin ja eh im Unternehmen, die bezahlen mir Ausbildungsvergütung. Ja, ich habe da so ein bisschen rumprogrammiert und ich habe da so ein paar Server installiert und ja, das hat das Unternehmen am Ende eigentlich nichts gekostet.
[1:20] Nee, so ist es nicht. Sondern alles, was du für dein Projekt machst und was auch im Unternehmen für dein Projekt gemacht wird, bereitgestellt etc., kostet irgendetwas. Das Geld dafür muss irgendwo herkommen. Auch deine Ausbildungsbegütung bezahlt ja irgendwer am Ende. Und ich spoiler schon mal, wer das macht, eure Kunden bezahlen das. Dein Chef überweist dir das zwar, aber der kriegt das Geld ja auch nicht aus dem, das fällt ja auch nicht vom Himmel, sondern das kommt von den Kunden, die am Ende dann eure Produkte kaufen oder eure Dienstleistungen in Anspruch nehmen, eure Waren kaufen, was auch immer. Und alle diese Kosten an deinem Projekt müssen auf die Kosten für die Kunden umgelegt werden, damit die am Ende das Ding bezahlen. Weil das Geld fällt nicht vom Himmel, auch wenn man das vielleicht glaubt. Das ist nicht so, das muss erwirtschaftet werden. Und ja, dein Projekt verursacht Kosten und die musst du einplanen. Und heute gehe ich mal auf die Kosten ein, die dabei gerne vergessen werden. Weil, was so die low hanging fruit ist, ich habe als Anwendungsentwickler zum Beispiel 80 Stunden gearbeitet, also plane ich mich 80 Stunden ein. Oder als Systemintegrator plane ich mich 40 Stunden ein. Ja, okay. Offensichtlich sind das Kosten natürlich anfallen, aber es gibt noch ganz viele mehr. Und da geht es halt eben nicht nur darum, was extra für dein Projekt zum Beispiel gekauft wurde. Also wenn extra für dein Projekt eine Hardware angeschafft wurde, ein Server gemietet wurde oder sowas. Das ist natürlich offensichtlich. Aber mir geht es heute um die vielleicht etwas versteckten Sachen, an die ganz viele Prüflinge leider nicht denken. und das sehe ich dann immer in den Dokus. Und zwar, ähm.
[2:42] Geht es mir um diese E-Da-Kosten. Das ist jetzt kein Fachbegriff. Ich weiß gar nicht, wo ich den selber mal gehört habe. Ich glaube, irgendwo im Rechnungswesenunterricht oder Vorlesung mal irgendwo. Also es geht darum, Dinge, die E-Da sind. Also es ist keine Abkürzung, sondern du formulierst das so, ja, der Server, der ist ja E-Da. Der steht ja unten im Keller, den haben wir ja E. Dann lasst uns doch nochmal eben mein Projekt da mit drauf installieren und fertig. Dann haben wir keine Kosten quasi. Also die Dinger sind ja E-Im-Unternehmen. Der Kollege sitzt da E. Der kriegt sein Gehalt. ja, also der muss ja nicht nur für mein Projekt jetzt mehr Geld bekommen. Deswegen, ja, EDA kostet nichts. Und das sind meine sogenannten EDA-Kosten. Und das ist leider Quatsch. Denn auch wenn die EDA sind, machen wir mal jetzt verschiedene Beispiele, den Softwareentwickler, der am Ende dein Projekt reviewen soll, ja. Der sitzt da vielleicht zwei Stunden dran. Und ja, der ist eh im Büro, die zwei Stunden. Aber in diesen zwei Stunden kann er ja nichts anderes machen, weil er ja deinen Code reviewt zum Beispiel, ne. Und das nennt man dann sogenannte Opportunitätskosten. Opportunity auf Englisch, Gelegenheit. Und das sind die Kosten der entgangenen Gelegenheit. Das heißt, während dieser Softwareentwickler zwei Stunden deinen Code reviewt, kann er eben nicht richtig coole Software fürs Unternehmen programmieren, mit der dann richtig Geld gemacht wird, sondern die zwei Stunden seiner Arbeitszeit sind dann halt weg, weil sie für dein Projekt draufgegangen sind. Oder machen wir was für die Systemintegratoren.
[3:59] Wir haben irgendwo einen Server stehen, auf dem eine neue Firewall installiert werden soll. Wenn die Firewall da läuft, kann der Server halt nicht noch 37 andere Applikationen hosten, Weil der vielleicht, keine Ahnung, so starkes Netzwerk eingebunden ist, dass gar keine andere Applikation mehr laufen kann, weil die gar keinen Netzwerktraffic mehr abkriegt. Oder die Firewall blockiert so viel CPU, dass einfach andere Applikationen auf dem Server nicht mehr laufen können. Und das heißt, der Server könnte für was anderes benutzt werden, wird er aber nicht, weil dein Projekt jetzt drauf läuft. Also sind das natürlich Kosten, die für dein Projekt anfallen. Auch wenn der Server eh schon da ist und nicht nochmal angeschafft werden muss. Aber jedes neue Projekt, was ich auf einen Server, ich bleibe jetzt mal bei dem Beispiel, installiere, belastet ja den Server. kostet CPUs, kostet RAM, kostet Strom und da kann in der Zeit halt vielleicht nichts anderes auf dem Server laufen, weil da ein Projekt draufläuft. Und jetzt überlegen wir mal weiter. Angenommen, alle Projekte würden das so machen. Ja, der Server ist ja eh da. Komm, ich installiere das mal mit drauf. Was glaubst du, wie lange kann man das machen? Also wie viele, ich sage jetzt mal, Software-Nemikungsprojekte, Web-Anwendungen oder so, kann ich auf dem Server installieren, bis der dann irgendwann mal die Grätsche macht, weil er eben keine CPU-RAM, was er auch immer mehr frei hat. Das kann man ja nicht unendlich betreiben. Die sind ja nicht unendlich skalierbar, diese Ressource, nur weil sie da sind.
[5:04] Und dann passiert Folgendes. Auf dem Server habe ich zehn Projekte laufen. Jetzt kommt das elfte Projekt und mit diesem elften Projekt kommt der Server jetzt an seine Grenzen. Was müssen wir machen? Neuen Server kaufen. Und wird jetzt die Anschaffung, der Anschaffungspreis für diesen Server, wird das jetzt auf dieses elfte Projekt gelegt. Das heißt, das elfte Projekt hat leider Pech gehabt, weil es aus Versehen das elfte Projekt war und hat jetzt zufällig einen neuen Server quasi zur Folge und muss dieses Projekt jetzt den kompletten Server bezahlen, einfach nur, weil es in der Reihenfolge zufällig an der falschen Position war. Sorry, so kann man noch nicht rechnen. Das geht nicht. Das heißt, jedes Projekt, jedes der elf Projekte muss anteilig diese Serverkosten tragen. Und das elfte übernimmt natürlich nicht die kompletten Kosten für den neuen Server, auf dem dann noch neun andere Applikationen wieder installiert werden können. Das muss natürlich verteilt werden. Und um wieder bei der Systemintegration auch mal ein Beispiel zu finden. Wir haben eine neue VM, die wir brauchen. Meintwegen die Firewall, da wird nichts mehr Hardware installiert, lassen wir auf einer VM laufen. Aber auch die VM braucht ja Ressourcen. Die blockiert vielleicht CPUs oder RAM im VMware-Cluster, der teuer lizenziert wird. Und für diese blockierten CPUs und RAM kann halt eben keine andere VM irgendwas anderes machen, was Geld einbringt zum Beispiel. Das heißt, diese Sachen kann man nicht einfach unter den Tisch fallen lassen. Die müssen einkalkuliert werden. Die müssen meistens anteilig einkalkuliert werden, weil halt meine Applikationen oft nicht die einzige auf dem Server ist. Da laufen halt noch andere. Aber ich darf diese Kosten halt nicht unter den Tisch fallen lassen.
[6:25] Es darf nicht Zufall sein, welches Projekt die Kosten trägt. Das muss fair sein, verteilt werden, anteilig über die Nutzung aller Projekte, die diese Ressource, ob es ein Mitarbeiter ist oder ein Server oder was auch immer. Meinetwegen auch eine Lizenz, die lese ich ja auch ganz oft bei Software-Mitglungs-Projekten, die ich ja nun mal hauptsächlich lese. Ja, wir haben eine IntelliJ-Lizenz, die packe ich zwar in meine Liste der Ressourcen, aber dafür setze ich keine Kosten an, weil die habe ich ja eh. Die IntelliJ-Lizenz kostet irgendwie, keine Ahnung, 1000 Euro im Jahr, aber für mein Projekt war die kostenfrei, weil die ist ja schon bezahlt. So kann man das, wie gesagt, nicht rechnen. Man muss das umlegen, anteilig. Ich spoilere das schon mal. Genau das ist die Lösung. Anteilig auf deinem Projekt umlegen. Das musst du im Zweifel auch nicht selber machen. Also keiner erwartet von dir in deiner Projektdokumentation, dass du jedes einzelne kostenanteiligstes Teilchen, was dir irgendwie einfällt in deinem Projekt, genau umlegst und Cent genau ausrechnest und so weiter. Dafür gibt es hoffentlich Mitarbeiter, Mitarbeiterinnen in deinem Unternehmen, die das machen, zum Beispiel im Rechnungswesen, in der Buchhaltung, im Personal, wo auch immer. Und die sagen dir dann einfach, was das pauschal kostet. So würde ich dir auch dringend empfehlen, das zu machen. Bitte berechnet das nicht selbst, da kannst du nur irgendwas vergessen, irgendwelche Fehler einbauen, noch eine Rundungsdifferenz und du hast irgendwas vergessen und das nehmen dir die Prüfenden dann auseinander, sondern lass dir einfach die Zahlen geben. Frag in der Personalabteilung, was kostet mich ein Softwareentwickler, eine Softwareentwicklerin pro Stunde?
[7:46] Zwei Stunden Code Review mal diesen Stundensatz, das sind die Kosten. Ende. Frag in deinem IT-Betrieb, in deinem Support, was kostet uns eigentlich eine VM im Jahr im Durchschnitt? Und dann kommt da raus, was auch immer, 100 Euro oder wie auch immer das da umgelegt wird. Und das packst du dann in deiner Projektkosten. Berechne das nicht selber, aber zeige, dass du dran gedacht hast und recherchiere die vernünftigen Zahlen in deinem Unternehmen und damit rechnest du dann. Genau das Gleiche eben bei meinem Lizenzbeispiel für IntelliJ. Das kann man ja auch umlegen. Das wird auch irgendwer wahrscheinlich gemacht haben. Da gibt es dann irgendeinen Kostenpunkt, den du noch mit reinnehmen kannst. Und im besten Fall machst du das nicht für jedes einzelne Ding, das da benutzt wird, sondern du kriegst einfach einen Gemeinkostensatz, den du dann mit in deine Projektkostenbrechnung mit einnimmst. Zum Beispiel anteilig auf deine Stunden aufgerechnet oder auf die der Kollegen, Kolleginnen, die mit dir da zusammen dran arbeiten. Das wäre meine Empfehlung dafür.
[8:38] Und dann, nächster Punkt, die laufenden Kosten. Die werden halt auch sehr oft vergessen. Jetzt haben wir diesen ganzen Kram da eingeplant. Ich habe meine Stundensätze, da sind auch die Gemeinkosten drin und alles super und Lizenzen umgelegt und tralala. Ja, aber dann ist es vorbei. So, dann kostet das Projekt einmalig 3.000 Euro. Beispiel ist eine Zahl, die sehr häufig vorkommt. Und dann amortisieren wir das und dann ist es fertig. Ja, und da wird dann vergessen, dass diese ganzen Ressourcen ja nicht umsonst laufen, wenn man sie einmal angeschafft hat. Beispiel, offensichtliches Beispiel, ein Server, der irgendwo steht, der verursacht Stromkosten, der muss gewartet werden, Updates müssen installiert werden, mal Stundensatz des IT-Admins, der das macht. Wir haben Lizenzen, wenn es ein Windows-Server ist zum Beispiel. Oder wenn das Ding nicht bei uns im Keller steht, in der Cloud, ja, die wird ja sogar stündlich oder täglich abgerechnet, was so ein Server da kostet, ja. Oder ich habe vielleicht Support-Verträge mit Dienstleistern, die für mich die Wartung machen, ja, so Full-Service-mäßig und so. Das sind alles Kosten, die auch anfallen, wenn dein Projekt beendet ist. Und angenommen, du hast jetzt ein Software-Dickle, die auf diesem Server läuft, der Server muss halt weiter betrieben werden, gepatcht werden. Der braucht Strom.
[9:36] Das heißt, auch das musst du natürlich einplanen in deine Kosten. Und das reduziert eventuell, nein, verlängert die Amortisationszeit. Aber das ist gar nicht schlimm. Im Gegenteil, es wäre schlimm, wenn du diese Kosten weglässt, weil das ist unrealistisch. Ich behaupte einfach, dass du kein IT-Projekt umsetzen kannst, was keine laufenden Kosten hat. Das ist einfach eine pauschale Aussage, die ich jetzt hier mal treffe, weil alles, was du entweder programmierst oder installierst oder konfigurierst oder was auch immer du machst in einem IT-Beruf, das wird nicht einmalig sein und dann wird das Ding ausgeschaltet, weggeschmissen, gelöscht, wie auch immer, sondern das wird ja dauerhaft laufen. Das ist hoffentlich die Idee deines Projekts. Und alles, was irgendwo läuft, verursacht wenigstens irgendwie Strom, Wartungs, Lizenzkosten, irgendwas fällt da ganz sicher an. Und es geht ja auch nicht darum, ob es vielleicht Cent-Beträge sind. Das ist ganz egal. Also es geht darum, dass du zeigst, dass du daran gedacht hast, dass diese Kosten anfallen. Ganz egal, wie hoch die sind. Aber du kannst nicht sagen, mein Projekt ist jetzt fertig und jetzt kümmere ich mich nicht mehr drum und jetzt verursacht das keine Kosten mehr. Doch. Und diese laufenden Kosten müssen halt eben auch von euren Kunden erwirtschaftet werden. Die muss irgendwer irgendwo mit einplanen, weil sonst kommt das Geld nicht rein und dann kostet dein Projekt im wahrsten Sinne des Wortes dein Unternehmen Geld, weil die Kunden über die Umlage das nicht wieder reinholen. Und das wollen wir vermeiden, weil wenn wir das alle machen würden, in allen Projekten, wäre das Unternehmen irgendwann pleite. Wenn alle sagen, so, das Projekt hat 5.000 Euro bezahlt, der Kunde bezahlt mir das jetzt einmalig, sagen wir mal mit Gewinnaufschlag, zahlt er 6.000 und dann ist es vorbei. Aber dass wir ihm jetzt noch jahrelang die Server betreiben müssen und einen monatlichen Betrag für uns fällig wird, habe ich leider vergessen.
[11:05] Ja, dann sind die Rechnungen alle bezahlt, aber nach zwei Monaten sind wir trotzdem insolvent, weil die ganzen Kosten, an die keiner gedacht hat, uns leider auffressen. So, das geht nicht. Also bitte auch die laufenden Kosten, und ich habe gerade ein paar genannt, immer mit einplanen, egal wie hoch und in die Riechse sind. Und da kannst du es ähnlich machen wie bei den EDA-Kosten. Du holst einfach Pauschalen. Beispiel hatte ich gerade schon. Was kostet denn der Betrieb einer VM im Jahr das Unternehmen zum Beispiel? Da wird dir hoffentlich ein IT-Admin irgendwie eine grobe Zahl nennen können. Und zur Not schätzt du die einfach. Im besten Fall lässt du sie von Kollegen schätzen, die da mehr Ahnung von haben, keine Frage. Aber wenn das nicht geht, gibt ja auch viele kleine Unternehmen, wo man vielleicht diese Zahlen gar nicht hat, dann schätzt du es halt selbst. Aber du musst jetzt nicht noch eine riesen BAB, so Betriebsabrechnungsbogen in deiner Prodoku machen, das will keiner sehen, das ist viel zu aufwendig. Aber wir wollen sehen, dass du diese Kosten gedacht hast. So, zum Abschluss jetzt noch mal ein paar konkrete Beispiele. Fangen wir mal mit System-Integration an. Was könnten solche Kosten jetzt sein, von denen ich heute rede und geredet habe? Wenn du einen neuen Server brauchst zum Beispiel, wenn du VM hast, was heute natürlich der Standard sein sollte oder Container, ganz egal. Auf jeden Fall brauchen die auch Ressourcen. CPU, RAM, irgendwie Storage vielleicht. Wir haben vielleicht ein Backup-System, was angebunden werden muss. Das wird auch belastet dadurch. Mehr Backup heißt, die Medien müssen vielleicht erweitert werden, weil du keinen Platz mehr hast und so weiter. Es gibt hoffentlich ein Monitoring-System für irgendwelche kritischen Sachen, die da laufen. Du hast natürlich auch die Zeit, vor allem deine eigene, aber auch die der Admins, die dann zum Beispiel Einrichtung, Wartung, eben den Betrieb übernehmen. Das sind alles Dinge, die dir anfallen können.
[12:34] Bei der Anwendungsentwicklung habe ich auch schon genannt. Die IDE, die meistens Geld kostet, manchmal auch nicht. Da musst du es natürlich nicht einen planen, klar. Aber irgendwelche anderen Software-Tools, die du noch im Einsatz hast. Vielleicht habt ihr ein dediziertes Testsystem, ein Staging-System. Das läuft auch nicht einfach so aus Spaß. Das kannst du anteilig mit reinnehmen. Du hast vielleicht eine Datenbank im Einsatz, die anteilig von dir genutzt wird. Eine CICD-Pipeline auf dem Bild-Server. Auch die kostet Ressourcen. Kann man vielleicht sogar genau sehen. Auch die läuft für fünf Minuten, kostet 20 Prozent CPU. Dann könntest du das ziemlich genau in Cent-Beträgen ausrechnen, was das kostet. Musst du nicht, wie gesagt, aber könntest du. Und das sind so ein paar Beispiele jetzt, an welche Kosten man denken kann für diese beiden Fachrichtungen.
[13:13] Für alle anderen IT-Berufe gilt das Ähnliche, aber im Kern geht es meist um solche Ressourcen, wie ihr genannt. So, was würde ich dir jetzt empfehlen für deine Projektdokumentation und Projektpräsentation? Nummer eins, mach erstmal eine Liste der Ressourcen. Das sehe ich auch in ganz vielen Projektdokumentationen, das ist für mich so ein Standardinhalt, finde ich auch gut. Was habe ich für Ressourcen gebraucht? Das geht vom Stuhl und Tisch, auf dem ich sitze, über den Laptop bis hin zu tatsächlich VM-Infrastruktur für mein Projekt am Ende. Alle diese Ressourcen erstmal auflisten. Und dann schaust du dir an, was kosten die denn? kriege ich vielleicht konkrete Kosten von meiner Personalabteilung für alle Menschen, von meinem IT-Betrieb oder aus dem Rechnungswesen oder aus dem Controlling für meine anderen Ressourcen oder kriege ich einfach einen pauschalen Satz genannt. Kann ja auch sein, dass man einfach die Sachen über Gemeinkosten auf die Stundensätze umlegt und dann hast du deinen Gemeinkostenzuschlag und damit ist alles abgedeckt. Ist ja auch okay. Hauptsache, du denkst dran und vergisst da nichts.
[14:05] Meistens wird es für die Projekte auf solche Stundensätze hinauslaufen. Da kannst du damit einplanen. Plus irgendwie eine Pauschale für den Betrieb pro Jahr oder so. Und dann hättest du ja normalerweise alles abgedeckt. Wie gesagt, du sollst das nicht alles im letzten kleinen Detail selber ausrechnen. Nimm am besten Pauschalen. Da kannst du am wenigsten falsch machen, aber zeigst trotzdem, dass du dran gedacht hast. Und wenn du dann noch irgendwie, keine Ahnung, dir den Server teilen musst mit fünf anderen Applikationen, dann kannst du das ja natürlich nochmal geteilt durch sechs machen. Dann hast du deine Anteile an diesen Kosten berechnet. Das ist ja manchmal nötig, habe ich aber noch nicht so oft gesehen. Wie gesagt, lass dir am besten Pauschalen geben und dann musst du da gar nicht so rumrechnen. So, und das planst du dann alles mit ein. Du hast deine einmaligen Kosten, wo dann hoffentlich schon diese EDA-Kosten anteilig mit drin sind, plus die laufenden Kosten. Und dann machst du eine ganz klassische Amortisationsrechnung, schaust dir an, wann habe ich diese Kosten wieder reingeholt. Aber das ist ein Thema für eine andere Episode.
[14:58] So, Fazit für heute. Kosten für dein Projekt. Denk dran, nicht nur das, was neu angeschafft wird für dein Projekt, sind Kosten, sondern auch alles, was schon da ist und was du nutzt, musst du potenziell mit einplanen in deinem Projektkosten. Die vorhandenen Ressourcen sind nie kostenlos. Genau diese EDA-Kosten, das ist ein geflügeltes Wort, weil die Leute sagen, es ist ja EDA. Ja, aber das muss trotzdem bezahlt werden. Die Dinger werden, und das haben wir heute noch gar nicht angesprochen, zum Beispiel, wenn du teure Hardware angeschafft hast, wird die abgeschrieben. Das heißt, über die Abschreibung wird der jährliche Wertverlust dieser Hardware zum Beispiel mit in deine Kostenplanung einfließen müssen.
[15:36] Also alles, was da ist, kostet auch Geld und muss mit eingeplant werden. Das ist die Kernauslage für heute. Und zweiter Punkt, laufende Kosten. Ich behaupte, dass jedes IT-Projekt irgendwelche laufenden Kosten produziert, außer es ist wirklich ein Wegwerfprojekt, was sofort gelöscht wird, nachdem es umgesetzt wurde. Aber das kann ich mir einfach nicht vorstellen.
[15:57] So, ich hoffe, du hast heute ein bisschen was mitgenommen, wie du deine Kosten für dein Projekt in deiner Projektdokumentation und Präsentation gut einplanst und sauber und ohne, dass du was vergisst, vorstellst. Und ja, dann wünsche ich dir viel Erfolg bei deiner Projektdokumentation und Präsentation.
Discover shows related to IT-Berufe-Podcast, based on actual content similarities. Explore podcasts with similar topics, themes, and formats, backed by real data.
