Werben im Podcast: IT-Berufe-Podcast

Um moderne Umschulungen in den IT-Berufen im Interview mit Nico Hartmann geht es in der einhundertachtundneunzigsten Episode des IT-Berufe-Podcasts. IT-Umschulungen können ein sinnvoller Weg in die Branche sein, unterscheiden sich aber je nach Bildungsträger und IHK teils stark in Qualität und Organisation. Wichtig sind ein guter Bildungsträger, viel Eigenmotivation, ein passendes Praktikum und ein bewusster Umgang mit KI, damit du nicht nur Lösungen erzeugst, sondern die nötige Denkweise für den IT-Beruf wirklich aufbaust. Inhalt IT-Umschulungen können ein guter Einstieg in die IT sein, wenn die Rahmenbedingungen stimmen. Im Interview mit Nico Hartmann wird deutlich, dass Umschulungen für viele Menschen ein sinnvoller Weg sind, sich beruflich neu zu orientieren, etwa bei drohender Arbeitslosigkeit oder wenn der bisherige Beruf nicht mehr ausgeübt werden kann. Gleichzeitig hängt der Erfolg stark vom Bildungsträger, von der eigenen Motivation und von den regionalen Vorgaben der IHK ab. Nico als Praxisbeispiel Nico arbeitet als Dozent und Ausbilder für IT-Umschulungen mit Schwerpunkt Fachinformatiker:in Anwendungsentwicklung. Er hat selbst eine außerbetriebliche Umschulung gemacht, danach mehrere Jahre als Softwareentwickler gearbeitet und ist anschließend in die Lehre gewechselt. Dadurch kennt er sowohl die Perspektive von Umschüler:innen als auch die von Ausbilder:innen. Was sich bei Umschulungen verändert hat Ein wesentlicher Unterschied zu früher liegt vor allem im Prüfungssystem: Früher gab es in seiner Umschulung nur die Abschlussprüfung. Heute schreiben Umschüler:innen wie Azubis die AP1 ungefähr zur Hälfte der Zeit und später die AP2. In der Umschulung liegt zwischen AP1 und AP2 oft nur etwa ein halbes Jahr. Dadurch ist die Zeit bis zur Abschlussprüfung deutlich komprimiert. Trotzdem hält Nico das für machbar, wenn die Teilnehmenden intensiv vorbereitet werden und bei Projektantrag, Doku und Prüfung eng begleitet werden. Dauer und Aufbau der Umschulung Die Umschulung dauert in Vollzeit in der Regel zwei Jahre, in Teilzeit entsprechend länger. Typisch ist ein Praktikum von sechs Monaten, in manchen IHK-Bezirken aber auch neun Monate. Wichtig dabei: Der Rahmenlehrplan ist grundsätzlich gleich. Die konkrete Gestaltung der Maßnahme ist aber je nach Bildungsträger unterschiedlich. Bei Karrieretutor wird versucht, den Unterricht vor dem Praktikum zu platzieren, damit die Teilnehmenden mit möglichst viel Fachwissen in den Betrieb gehen. Unterschiedliche Vorgaben der IHK Ein großes Thema sind die teils sehr unterschiedlichen Regeln der IHKs. Das betrifft unter anderem: Dauer des Praktikums Formulare und organisatorische Abläufe Umgang mit Berichtsheften Anforderungen an Ausbilder:innen Durchführung der mündlichen Ergänzungsprüfung Da die Teilnehmenden bundesweit an verschiedenen Standorten sitzen, müssen sie auch bei unterschiedlichen IHKs geprüft werden. Das führt laut Nico zu viel organisatorischem Aufwand und teilweise kuriosen Einzelfällen. Unterrichtsmodell und Organisation Der Unterricht bei Karrieretutor findet remote statt, die Teilnehmenden sitzen aber je nach IHK-Vorgaben an einem physischen Standort. Häufig gilt eine 51%-Präsenzregel, in manchen Regionen gibt es strengere Anforderungen. Das Unterrichtsmodell ist grob so aufgebaut: Vormittags: dozentengeführter Unterricht Nachmittags: betreute Lernphase mit Aufgaben, Projekten oder Recherchen Diese Lernphase soll den Teilnehmenden ermöglichen, in ihrem eigenen Tempo zu arbeiten, Fragen zu stellen, selbstständiges Lernen einzuüben, eigene Projekte umzusetzen. Gerade dieses selbstständige Lernen wird als wichtige Vorbereitung auf den späteren IT-Beruf gesehen. Finanzierung und Kostenträger Als typische Kostenträger werden genannt: Bundesagentur für Arbeit Rentenversicherung Bundeswehr Für Praktikumsbetriebe ist das Praktikum laut Nico komplett kostenfrei. Der Betrieb muss vor allem eine geeignete Betreuung sicherstellen. Genau das ist aber häufig ein Problem, weil viele Unternehmen den nötigen Betreuungsaufwand nicht leisten wollen. Praktikum: entscheidend und oft schwierig Das Praktikum ist ein zentraler Bestandteil der Umschulung und muss in einem externen Betrieb stattfinden. Eine Durchführung beim Bildungsträger selbst ist inzwischen in der Regel nicht mehr erlaubt. Die Praktikumssuche läuft über: Kontakte und Kooperationslisten des Bildungsträgers eigene Bewerbungen der Teilnehmenden häufig auch Initiativbewerbungen Nico empfiehlt, Betriebe vor einer Bewerbung direkt anzurufen und den Vorteil eines kostenfreien Praktikums klar anzusprechen. Trotzdem ist die Suche gerade in der Anwendungsentwicklung aktuell oft schwierig. Situation am Arbeitsmarkt und Einfluss von KI In der Anwendungsentwicklung ist die Lage laut Nico derzeit angespannt. Viele Unternehmen stellen weniger Junioren ein. Als möglicher Grund wird auch KI genannt. Dabei sieht Nico zwei gegensätzliche Entwicklungen: Manche Unternehmen glauben, dass KI Junioren überflüssig macht. Andere erkennen, dass KI helfen kann, Junioren schneller weiterzuentwickeln. Er warnt davor, Junior-Stellen wegfallen zu lassen, weil dadurch später erfahrene Fachkräfte fehlen könnten. Schlechter Ruf mancher Umschulungen Ein zentrales Problem ist laut Nico die stark schwankende Qualität der Bildungsträger. Nico berichtet von Fällen, in denen Teilnehmende: kaum echten Unterricht hatten, nur PDFs bekommen haben, wochenlang ohne Betreuung gelassen wurden, häufig wechselnde Dozent:innen hatten. Das schade nicht nur den einzelnen Umschüler:innen, sondern auch dem Ruf von Umschulungen insgesamt. Gleichzeitig betont er, dass es auch gute Anbieter gibt, die ihre Teilnehmenden intensiv begleiten. Wie du einen guten Bildungsträger erkennst Als wichtigste Empfehlung nennt Nico: Schau dir den Bildungsträger genau an. Verlass dich nicht nur auf Werbeversprechen. Sprich möglichst mit aktuellen oder ehemaligen Teilnehmenden. Informiere dich auch über Erfahrungsberichte, zum Beispiel online. Besonders wichtig ist aus seiner Sicht, ob echter Unterricht stattfindet, Dozent:innen erreichbar sind, Betreuung bei Fragen vorhanden ist, die Fachqualifikation möglichst konstant von denselben Dozent:innen begleitet wird. Rolle der eigenen Motivation Neben dem Bildungsträger spielt die Eigenmotivation eine große Rolle. Nico betont, dass Teilnehmende ihren Erfolg verbessern können, wenn sie: sich wirklich reinhängen, den Rahmenlehrplan und Prüfungskatalog selbst im Blick behalten, eigene Projekte bauen, neugierig bleiben, Fehler als normalen Teil des Lernens akzeptieren. Gerade in der IT sei es wichtig, sich auch selbstständig neue Themen zu erschließen. KI in der Umschulung KI wird im Unterricht nicht pauschal abgelehnt, aber bewusst eingesetzt. Wichtig ist dabei: Gerade am Anfang soll KI eher nicht das Denken übernehmen. Zuerst muss die grundlegende Denkweise beim Programmieren aufgebaut werden. KI soll eher helfen, den Weg zur Lösung zu verstehen, nicht einfach nur Lösungen ausspucken. Wer KI-generierten Code nutzt, muss ihn auch verstehen und bei Bedarf umschreiben können. Im fortgeschritteneren Verlauf wird KI dann als unterstützendes Werkzeug genutzt, etwa bei Projekten oder als Einstiegshilfe für Code-Strukturen. Einstieg ins Programmieren Nico versucht, im Unterricht möglichst schnell von trockenen Grundlagen zu kleinen Projekten zu kommen. Statt lange bei einfachen Einführungsbeispielen zu bleiben, arbeitet er früh mit konkreten Anwendungen wie Galgenraten. Sein Ansatz: Grundlagen wie Kontrollstrukturen und Schleifen müssen sitzen. Danach sollen die Teilnehmenden möglichst schnell etwas bauen. Sichtbare Ergebnisse motivieren und fördern das Verständnis. Verwendete Sprachen und Inhalte Die Umschulung ist in verschiedene Phasen gegliedert. Kernqualifikation Im ersten Jahr lernen alle Berufe gemeinsam die Grundlagen, darunter: betriebswirtschaftliche Inhalte Netzwerke Inhalte für die AP1 Programmiergrundlagen mit Python Fachqualifikation Anwendungsentwicklung Hier liegt der Schwerpunkt auf Java als objektorientierter Sprache. Zusätzlich werden weitere Technologien behandelt, darunter: Python Java C# als Intensivkurs HTML, CSS JavaScript teilweise TypeScript Webentwicklung allgemein Ziel ist, nicht nur eine einzelne Sprache auswendig zu lernen, sondern ein Verständnis für Programmierkonzepte und Übertragbarkeit zu entwickeln. Daten- und Prozessanalyst:in in der Umschulung Besonders interessant ist, dass bei Karrieretutor auch die Umschulung zum/zur Fachinformatiker:in Daten- und Prozessanalyse angeboten wird. Laut Nico ist die Nachfrage dort sogar sehr hoch, auch weil viele andere Bildungsträger diesen Beruf nicht anbieten. Wichtige Punkte dazu: Der Beruf ist noch relativ neu. Die Fachqualifikation musste erst entwickelt und praktisch erprobt werden. In diesem Bereich spielen Datenverständnis, mathematische Grundlagen und die passende Denkweise eine große Rolle. Themen wie Machine Learning, Clustering oder lineare Regression gehören dazu. Anders als an manchen Berufsschulen werden Daten- und Prozessanalyst:innen dort nach der gemeinsamen Grundphase nicht mit Anwendungsentwickler:innen zusammengelegt, weil sie unterschiedliche Prüfungsinhalte und Anforderungen haben. Regulierung und Qualitätssicherung Zwar gibt es mit der AZAV bereits ein Zertifizierungssystem für Bildungsträger, Nico sieht darin aber vor allem eine Prüfung der Dokumentation und weniger der tatsächlichen Unterrichtsqualität. Er hält es für denkbar, dass die Kontrolle der inhaltlichen Qualität und der Verfügbarkeit der Dozent:innen an manchen Stellen nicht ausreicht. Zentrale Empfehlungen zum Schluss Zum Abschluss bleiben vor allem diese Punkte hängen: Umschulungen sind grundsätzlich ein wertvolles Instrument. Der Erfolg hängt stark vom Bildungsträger ab. Gute Betreu

Um das Einsparen von wertvoller Zeit beim Erstellen der IHK-Projektdokumentation geht es in der siebzehnten Episode der Shorts des IT-Berufe-Podcasts. Ich zeige dir, wie du bei der IHK-Projektdokumentation trotz knapper Zeit realistischer arbeiten kannst: Nicht alles entsteht erst am Ende, denn viele Artefakte wie Diagramme, Modelle oder Anforderungsdokumente gehören sowieso zur Projektdurchführung und können direkt wiederverwendet werden. Zeit sparst du vor allem, wenn du dein Textsatzsystem vorher beherrschst, mit Vorlage und Versionierung arbeitest, Texte parallel zum Projekt sammelst und bei Bedarf Sprache-zu-Text mit KI nutzt. Inhalt Grundidee Ich setze den Fokus darauf, wie du bei der Projektdokumentation Zeit sparen kannst, obwohl die vorgegebenen 40 oder 80 Projektstunden und insbesondere die oft nur 8 bis 12 Stunden für die Doku sehr knapp sind. Der zentrale Gedanke ist: Du musst nicht die komplette Dokumentation erst am Ende von null auf erstellen. Viele Inhalte deiner Projektdokumentation entstehen bereits während der normalen Projektarbeit und sind damit bereits in der Projektzeit enthalten. Artefakte entstehen schon im Projekt Bei einem professionell durchgeführten IT-Projekt erstellst du ohnehin Unterlagen und Ergebnisse, die später in die Projektdokumentation übernommen werden können, zum Beispiel: ER-Modelle Netzwerkpläne Gannt-Diagramm oder Netzplan Prozessabläufe Klassendiagramme Mockups Tabellenmodelle Anforderungen Testüberlegungen Planungsunterlagen Dokumentationen für Kund:innen, Admins oder Entwickler:innen Diese Artefakte gehören zur normalen Projektarbeit und müssen nicht noch einmal extra nur für die Doku erzeugt werden. Die eigentliche zusätzliche Arbeit in der Dokumentationszeit betrifft daher vor allem den Fließtext. Professionelle Projektarbeit statt "einfach machen" Ein wichtiges Missverständnis ist, dass manche Prüflinge glauben, die gesamte Doku müsse erst in der dafür eingeplanten Zeit entstehen. Tatsächlich zeigt die Dokumentation vor allem, dass du professionell arbeitest: du planst vor der Umsetzung du erhebst Anforderungen du entwirfst Lösungen du überlegst dir Testverfahren du dokumentierst nachvollziehbar Gerade das soll in der Abschlussprüfung sichtbar werden. Es geht nicht darum, einfach nur etwas umzusetzen, sondern nachvollziehbar und strukturiert zu arbeiten. Textsatzsystem vorher beherrschen Ein großer Hebel zum Zeitsparen ist ein geeignetes Textsatzsystem. Das kann zum Beispiel sein: LaTeX Microsoft Word LibreOffice Markdown AsciiDoc Die konkrete Technologie ist weniger wichtig als der professionelle Umgang damit. Entscheidend ist, dass du semantisch arbeitest statt manuell zu formatieren. Wichtig dabei Überschriften sollten als echte Überschriften ausgezeichnet werden Inhaltsverzeichnisse sollten automatisch generiert werden Verweise, Nummerierungen und Formatierungen sollten vom System übernommen werden du solltest nicht während des Schreibens ständig manuell fett, kursiv oder Größen anpassen Wenn du mehr Zeit mit Formatierung als mit Inhalten verbringst, beherrschst du dein Werkzeug noch nicht gut genug. Deshalb solltest du dich lange vor der Projektdurchführung mit deinem Textsatzsystem beschäftigen und nicht erst kurz vor der Prüfung. Vorbereitung vor der eigentlichen Projektzeit Niemand erwartet, dass du erst innerhalb der 40 oder 80 Stunden lernst, wie du mit Word, LaTeX oder einem anderen System professionell arbeitest. Diese Vorbereitung sollte vorher passieren. Gerade weil die Projektdokumentation für viele IT-Azubis das erste große Dokument dieser Art ist, solltest du dir früh genug Zeit nehmen, den Umgang mit dem Werkzeug zu lernen. Inkrementell arbeiten und versionieren Die Dokumentation sollte nicht erst am Ende geschrieben werden, sondern parallel zum Projekt wachsen. Dafür empfiehlt sich eine Versionierung, zum Beispiel mit Git. Vorteile davon: du kannst Zwischenstände sichern du kannst Änderungen nachvollziehen du kannst ältere Versionen wiederherstellen du hast dein Dokument jederzeit griffbereit Sinnvoll ist es, die Dokumentation schon vor Projektbeginn technisch aufzusetzen und dann während jeder Projektphase fortlaufend zu ergänzen. Beispiel: Du erstellst ein ER-Modell. Direkt danach notierst du Stichpunkte oder formulierst schon erste Sätze für das passende Kapitel in der Doku. So dokumentierst du Inhalte dann, wenn sie noch frisch im Kopf sind, statt Wochen oder Monate später rekonstruieren zu müssen. Vorlagen nutzen Ein weiterer klarer Zeitsparer ist die Nutzung einer Vorlage, etwa für: Deckblatt Inhaltsverzeichnis Kopf- und Fußzeilen Seitenzahlen Nummerierung von Überschriften grundlegende Formatierung Diese technische Vorarbeit hat nichts mit deiner eigentlichen Prüfungsleistung zu tun. Du bekommst keine bessere Note dafür, dass du Formatvorlagen oder Layouts selbst baust. Deshalb ist es sinnvoll, eine fertige Vorlage zu verwenden und deine Zeit lieber in Inhalt und Struktur zu investieren. Artefakte so erstellen, dass du sie wiederverwenden kannst Wenn du Diagramme und andere Inhalte später in Doku und Präsentation verwenden willst, solltest du sie von Anfang an so anlegen, dass sie dafür geeignet sind. Ein Problem dabei ist das unterschiedliche Format: Projektdokumentation: meist DIN A4 Hochformat Präsentation: meist 16:9 Querformat Daher kann es sinnvoll sein: entweder direkt zwei Varianten eines Diagramms zu erstellen oder zumindest schon bei der Erstellung auf gute Verwendbarkeit im Hochformat zu achten Wenn du nur eine Version priorisieren kannst, sollte sie für die Dokumentation optimiert sein, weil ein PDF im Hochformat weniger flexibel ist als eine Präsentation, in der du mit Zooms oder Animationen arbeiten kannst. Inhalte aus dem Projektantrag wiederverwenden Auch der Projektantrag enthält oft schon Texte, die du in die Projektdokumentation übernehmen kannst, zum Beispiel: Projektbegründung Zielbeschreibung Anforderungen Testideen oder Abnahmekriterien kurze Unternehmensvorstellung Beschreibung von Stakeholdern Wenn du diese Texte selbst geschrieben hast, ist ihre Wiederverwendung kein Plagiat. Du kannst sie übernehmen, anpassen, kürzen oder erweitern, statt dieselben Inhalte noch einmal neu zu formulieren. Sprache-zu-Text mit KI nutzen Ein zusätzlicher Tipp zum Zeitsparen ist, Fließtexte nicht nur zu tippen, sondern einzusprechen und per KI transkribieren zu lassen. Der Vorteil: Sprechen ist meist schneller als Tippen Gedanken lassen sich oft direkter festhalten moderne Transkriptions-KI kann Satzzeichen, Formatierung und kleine Versprecher teilweise schon gut verarbeiten Dabei gilt aber: achte auf Datenschutz achte auf Security gib keine ungeeigneten sensiblen Daten leichtfertig an externe Systeme Beispiele für wiederverwendbare Artefakte aus Projektphasen Je nach Projektphase können verschiedene Unterlagen direkt für die Doku vorbereitet werden. Analysephase Use-Case-Diagramme Lastenheft Pflichtenheft andere Formen der Anforderungsermittlung, z.B. User Storys Entwurfsphase Architekturdiagramme UML-Diagramme Mockups Datenmodelle Schnittstellen- oder API-Beschreibungen Dokumentationsphase Benutzerdokumentation Kundendokumentation Anwendungsdokumentation Entwicklungsdokumentation Administrationsdokumentation Diese Unterlagen entstehen oft ohnehin im Projekt und können ganz oder in Auszügen in die Projektdokumentation übernommen werden. Fazit Die wichtigste Idee ist, deine Projektdokumentation als wachsendes Dokument zu sehen und nicht als etwas, das du erst am Ende in einem Stück schreibst. Zeit sparst du vor allem dann, wenn du: dein Textsatzsystem vorher sicher beherrschst mit semantischer Textverarbeitung arbeitest eine Vorlage nutzt deine Dokumentation früh aufsetzt und versionierst Texte parallel zum Projekt sammelst oder einsprichst Artefakte aus der Projektdurchführung direkt wiederverwendest Inhalte aus dem Projektantrag übernimmst So kannst du dich in der knappen Dokumentationszeit stärker auf den eigentlichen Inhalt konzentrieren statt auf Technik, Formatierung und nachträgliches Rekonstruieren. Links Permalink zu dieser Podcast-Episode RSS-Feed des Podcasts Word-Vorlage für die Projektdokumentation der IT-Berufe Erklärvideo zur Arbeit mit Word bei YouTube: Word-Vorlage für die Projektdokumentation der IT-Berufe LaTeX-Vorlage zur Projektdokumentation für Fachinformatiker Anwendungsentwicklung Wispr Flow Transkription der gesamten Episode Automatisch erzeugte Transkription der Episode [0:21] In den letzten Shorts habe ich jetzt öfter über die Zeitvorgabe für das Erstellen der Projektdokumentation in den IT-Berufen bei der IHK-Abschlussprüfung gesprochen. Einige IHK erlauben ja das Erstellen außerhalb der 40 oder 80 Stunden. Andere zwingen das in diese Zeit mit rein. Und das ist natürlich alles super unrealistisch, habe ich jetzt alles schon ein paar Mal erzählt. Also wie soll ich jetzt in 10, 12, manchmal sogar nur 8 Stunden eine 30, 40, 50-seitige PDF erstellen zu meinem Projekt? Das ist ja nicht machbar. Das wissen wir jetzt alle auch. Jetzt wollen wir uns heute mal damit beschäftigen, wie es vielleicht doch einigermaßen realistisch ist, so ein Dokument innerhalb dieser Zeitvorgabe zu erstellen. Dass ich immer noch glaube, dass das utopisch ist und man viel länger dafür einplanen muss, als diese Zeitvorgabe ist. Das habe ich schon im separaten Short besprochen. Aber heute wollen wir mal gucken, wie kannst du denn tatsächlich Zeit sparen beim Erstellen deiner Projektdokumentation. Grundsätzlich ist das Missverständnis vielleicht, dass wenn du jetzt in deiner Zeitplanung, sagen wir mal zwölf Stunden für die Doku einplanst, dass du die komplette Doku von Seite 1 bis Seite 50 innerhalb dieser Zeit erstellen musst. Das ist aber vielleicht gar nicht der Fall. Denk mir mal an so ein Softwareentwicklungsprojekt und du hast einen Anhang, da ist ein Kla

Um das Korrekturlesen der Projektdokumentation geht es in der sechzehnten Episode der Shorts des IT-Berufe-Podcasts. Ich empfehle dir ganz klar, deine Projektdokumentation vor der Abgabe gegenlesen zu lassen. Korrekturlesen durch dein:e Ausbilder:in, andere Personen oder auch eine KI ist aus meiner Sicht eine normale Qualitätssicherung und kein Problem, solange die Doku weiterhin deine eigene Arbeit bleibt und dir niemand den Inhalt oder die Formulierung vollständig abnimmt. Gerade weil formelle Gestaltung mitbewertet wird und die Prüfungsvorgaben oft unrealistisch sind, wäre es eher unklug, auf diese Prüfschleife zu verzichten. Inhalt Gegenlesen ist sinnvoll und aus meiner Sicht erlaubt Ich halte es für sinnvoll, die Projektdokumentation vor der Abgabe gegenlesen zu lassen. Gemeint ist das PDF (oder das ausgedruckte Dokument), das du als Prüfungsartefakt beim Prüfungsausschuss einreichst. Die kurze Antwort lautet: Ja, lass jemanden drüber schauen! Warum das wichtig ist Die Vorgaben rund um Projektzeit und Dokumentation bei den einzelnen IHKen wirken oft unrealistisch. Wenn erwartet wird, dass eine längere Projektdokumentation – manchmal 50 oder mehr Seiten – in sehr wenig Zeit vollständig fehlerfrei erstellt wird, ist das kaum praktikabel. In der Praxis sind viele Dokumentationen ohnehin schon schwer lesbar, etwa durch: Rechtschreib- und Grammatikfehler uneinheitliche Formatierung wechselnde Perspektiven im Text unvollständige oder abgebrochene Sätze Deshalb ist Gegenlesen aus meiner Sicht eine normale und notwendige Absicherung der Qualität. Selbstständigkeit bedeutet nicht: keine Korrekturhilfe Auch wenn du in der Prüfung bestätigst, dass du die Projektarbeit selbstständig erstellt hast, sehe ich Korrekturlesen nicht als Widerspruch dazu. Es geht dabei nicht darum, dass dir jemand die Dokumentation schreibt, sondern dass Fehler gefunden und Formulierungen verständlicher gemacht werden. Was nicht gemeint ist Nicht in Ordnung wäre es, wenn dir jemand anderes oder eine KI die Doku vollständig schreibt oder wesentliche inhaltliche Arbeit übernimmt. Die Dokumentation soll weiterhin deine eigene Leistung zeigen. In Ordnung ist dagegen zum Beispiel: Rechtschreibung prüfen lassen Grammatik prüfen lassen auf unklare Formulierungen hinweisen lassen formelle Fehler korrigieren lassen eine Qualitätssicherung durch eine zweite Instanz einbauen Bewertung: Form zählt mit Auch wenn der Inhalt des Projekts wichtiger ist als die äußere Form, spielt die formelle Gestaltung bei der Bewertung mit hinein. Fehler in der Dokumentation können sich also auf die Note auswirken. Wenn andere Prüflinge ihre Doku gegenlesen lassen und du nicht, kann dir das einen Nachteil bringen. Eine fehlerhafte Doku wirkt schnell unsorgfältig, selbst wenn das fachliche Projekt gut ist. Bezug zur echten IT-Praxis In der realen IT-Arbeit ist Qualitätssicherung selbstverständlich. Beispiele dafür sind: Code-Reviews Pull-Requests Vier-Augen-Prinzip Pair-Programming statische Codeanalyse Auch in echten Projekten würde niemand wichtige Ergebnisse ungeprüft weitergeben. Deshalb ist es aus meiner Sicht nur logisch, auch die Projektdokumentation als wichtiges Prüfungsartefakt prüfen zu lassen. Wirkung von Fehlern nach außen Rechtschreibfehler haben zwar nichts mit Programmieren oder Netzwerktechnik zu tun, sie können aber den Eindruck erwecken, dass unsauber gearbeitet wurde. Genau dieser Eindruck kann sich auch auf die Bewertung auswirken. Wenn schon die Doku nachlässig wirkt, wird schnell auch an der Sorgfalt im Projekt gezweifelt. KI als Prüfwerkzeug Ich halte es für völlig in Ordnung, KI zur Korrektur von Rechtschreibung, Grammatik oder Verständlichkeit einzusetzen. Entscheidend ist, dass die KI nicht deine eigentliche Arbeit übernimmt, sondern nur als Qualitätssicherung dient. Konkretes Beispiel aus einer IHK Als Beispiel habe ich unten ein Merkblatt der IHK München verlinkt. Dort steht ausdrücklich, dass die fertige Dokumentation von möglichst vielen Personen quergelesen werden soll, idealerweise sowohl von fachbezogenen Personen als auch von Personen, die nicht in der Materie stecken. Das zeigt, dass Gegenlesen nicht nur geduldet, sondern teilweise sogar empfohlen wird. Lassen Sie die fertige Dokumentation von möglichst vielen Personen querlesen. Am besten von Fachbezogenen Personen, aber auch von Personen die nicht in der Materie drin sind. Achten Sie auch auf die Rechtschreibung in der Dokumentation, diese wird zwar nicht bewertet trägt, aber zum äußeren Erscheinungsbild erheblich mit. Fazit Mein zentraler Tipp ist: Lass deine Projektdokumentation auf jeden Fall gegenlesen. Wenn du niemanden im Unternehmen oder im privaten Umfeld hast, kann auch eine KI diese Rolle für die Korrektur und Qualitätssicherung übernehmen. Wichtig ist nur, dass die Doku inhaltlich und als Leistung deine eigene bleibt. Links Permalink zu dieser Podcast-Episode RSS-Feed des Podcasts Orientierungshilfe zur Dokumentation IT-Berufe – IHK München Transkription der gesamten Episode Automatisch erzeugte Transkription der Episode [0:21] So, heute habe ich mal wieder ein Thema mitgebracht, was gerade in Zeiten von KI besonders oft nachgefragt wird. Und zwar, kann ich meine Projektdokumentation eigentlich korrigieren, beziehungsweise gegenlesen lassen oder wie auch immer. Also die Projektdokumentation, die ich als Prüfungsartefakt dem Prüfungsausschuss übergebe, das PDF, was je nach IHK zwischen 30 und 60 Seiten lang ist oder mal weniger, mal mehr, darf ich da eigentlich jemanden rübergucken lassen. Ja, und kurze Antwort. Ja, auf jeden Fall mach das. Du bist dumm, wenn du niemanden drüber gucken lässt. Ja, das ist meine persönliche Antwort. Wenn man dich direkt danach fragt, hast du da jemanden drüber gucken lassen, dann frag lieber jemanden, der schon mal bei deinem Prüfungsausschuss Prüfung gemacht hat, was die da vielleicht erlauben und was nicht. Also Nummer eins, wir wissen, dass die Zeitplanung und die Vorgaben und so weiter, die man bei so einer IHK für seine Prüfung bekommt, größtenteils unrealistisch, utopisch, fragwürdig sind. Ich habe schon Episoden dazu gemacht. Wie viel Zeit darf man für die Projektdokumentation aufwenden? Muss das in die Projektzeit mit rein und so weiter? Und das sind teilweise alles so unrealistische Vorgaben. Das weiß sowieso jeder, der einigermaßen Bezug zur IT hat, dass das alles hinten und vor nicht passt. Und jetzt unterschreiben die Prüflinge natürlich auch, zumindest bei unserer IHK, bei anderen gibt es sicherlich etwas Ähnliches, so etwas wie. [1:45] Ich bestätige, dass ich die Projektarbeit komplett selbstständig umgesetzt habe. So oder in anderen Worten. Und jetzt kann man natürlich hinterfragen, Moment, komplett selbstständig, wenn jetzt jemand Korrektur gelesen hat, ist das dann noch selbstständig? Und natürlich kann man auch fragen, wenn dieser jemand eine KI ist. [2:02] Ist das eigentlich eine KI-Unterstützung dann? Oder also darf ich das eigentlich oder nicht? Und jetzt muss man aus meiner Sicht ein bisschen unterscheiden, die Realität und dieses Prüfungsgedöns, was wir hier gerade vor uns haben. Und ich habe schon mehrfach in anderen Episoden gesagt, dass alle sowieso wissen, dass die Zeitplanung und Vorgaben alles super unrealistisch ist. Und wenn ich jetzt tatsächlich von einem Prüfling erwarte, so einen 50 Seiten PDF in, wenn ich ganz viel Pech habe, 12 Stunden maximal laut, Projektvorgabe, fehlerfrei mit korrekter Kommasetzung und ich weiß nicht was, dass alle Referenzen auf Bilder aufgelöst und alles, was man halt bei so einem Dokument falsch machen kann, ist richtig gemacht worden. Dass man das hinkriegt in der kurzen Zeit, das ist absolut unrealistisch. Und wenn wir das wirklich erwarten würden, dass die Leute nur diese maximale Zeit investieren würden, dann könntest du die Texte nicht mehr lesen. Also ich habe so schon Dokus, die einfach irgendwo teilweise mitten im Satz einfach enden oder wo einfach Kraut und Rüben drin ist und mal ist Blocksatz, dann wieder Flattersatz und munter von Ich in Perspektive in eine andere gewechselt. Und also es ist sowieso teilweise schon sehr schwierig, solche Sachen zu lesen. Und wenn wir den Leuten dann tatsächlich auch nur 10 Stunden dafür geben würden, dann könntest du gar nicht mehr lesen am Ende. Das ist einfach Quatsch. So, und das wissen alle an der Prüfung Beteiligten, insbesondere die Prüfenden. [3:17] Und deswegen kann ich dir nur Empfehlung geben, lass auf jeden Fall jemanden drüber gucken. [3:22] Und wenn jemand dir vorwerfen würde, dass du das nicht selbst gemacht hast, wie will die Person es denn beweisen? Ich meine, sind wir mal ganz ehrlich. Wenn ein Ausbilder, Ausbilderin da mal drüber guckt und ihr sagt, hier, das musst du umformulieren und hier ist ein Komma-Fehler. Wer will das denn im Nachhinein beweisen, dass das stattgefunden hat? Und dass du nicht tatsächlich einfach mit Microsoft Word die Rechtschreibprüfung gemacht hast und die grammatikalische Prüfung und da kam es dann her. Also das kann doch kein Mensch mehr nachweisen. Und genauso wenig kann man dir nachweisen, dass du KI eingesetzt hast, um Rechtschreibfehler zu korrigieren oder Sätze umzuformulieren. Das kann doch niemand beweisen. Und selbst wenn ich das Ding in so einen KI-Checker reinhaue, sind die Ausgaben, die da rauskommen, sowieso 100 Prozent, ja, das ist sicherlich KI generiert. Weil die wissen es ja auch nicht. Woran sollen sie es denn festmachen? [4:05] Ja gut, wenn da ein paar zu viele Bindestriche drin sind, okay. Aber ganz ehrlich, ich lese schon seit Jahr, ich kann inzwischen sagen, Jahrzehnten lese ich Projektdokumentation. Und so viel Welche, Welcher, Welches, wie ich da schon gelesen habe, das habe ich im wahren Leben selten gehört. Also die Leute fangen an zu schreiben, als würden sie Professor Dr. Tralala sein bei ihrer Projektarbeit. So

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. Links Permalink zu dieser Podcast-Episode RSS-Feed des Podcasts 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 d

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. 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. Weniger Zeit ist zwar erlaubt, aber unklug 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. Pufferzeit im Projektantrag 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. Warum ein abgelehnter Antrag problematisch ist 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. Abweichungen vom Projektantrag helfen bei Überziehung nicht 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. Umgang mit Abweichungen während des Projekts 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. Fazit 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. Links Permalink zu dieser Podcast-Episode RSS-Feed des Podcasts FIAusbV: Verordnung über die Berufsausbildung zum Fachinformatiker und zur Fachinformatikerin Transkription der gesamten Episode Automatisch erzeugte Transkription der Episode [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:2

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. 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. Einschätzung zur Praxis 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. Rolle von IHK und DIHK 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 Oldenburg, drin 15-20%, https://www.ihk.de/oldenburg/geschaeftsfelder/ausbildungweiterbildung/ausbildung/tipps-zur-ausbildung/it-berufe-leitfaden-abschlusspruefung-6733866 Gera, drin 20%, https://www.ihk.de/blueprint/servlet/resource/blob/3872458/df0b97a582369d0c4ae8bd448b1785aa/it-ihk-information-veroeffentlichung-internet-20170907-data.pdf 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. Was du für deine Planung mitnehmen kannst 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. Praktische Empfehlung 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. Fazit 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. Links Permalink zu dieser Podcast-Episode RSS-Feed des Podcasts FIAusbV: Verordnung über die Berufsausbildung zum Fachinformatiker und zur Fachinformatikerin Umsetzungsempfehlungen für die Durchführung der Abschlussprüfung in den IT‐Berufen (DIHK) Transkription der gesamten Episode Automatisch erzeugte Transkription der Episode [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, da

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 Wirtschafts- und Sozialkunde (WISO) Wann die Abschlussprüfung bestanden ist Die Abschlussprüfung ist bestanden, wenn folgende Bedingungen erfüllt sind (siehe Gewichtung der Prüfungsbereiche und Anforderungen für das Bestehen der Abschlussprüfung): 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. Wann du in eine MEP musst 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. Wer die MEP beantragen muss 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. In welchen Prüfungsbereichen die MEP möglich 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 Wie die MEP bewertet wird 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 Was diese Gewichtung praktisch bedeutet 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. Wie der Ablauf organisiert ist 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. Welche Inhalte in der MEP drankommen können 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. Wie du dich vorbereiten kannst 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. Einschätzung zur MEP 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. Wichtigstes Fazit 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. Links Permalink zu dieser Podcast-Episode RSS-Feed des Podcasts Themen der schriftlichen IHK-Prüfungen der IT-Berufe Gewichtung der Prüfungsbereiche und Anforderungen für das Bestehen der Abschlussprüfung Mündliche Ergänzungsprüfung Prüfungsrechner aller Berufe von A-Z Transkription der gesamten Episode Automatisch erzeugte Transkription der Episode [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

Um den Umgang mit Fehlern in der Projektdokumentation in der Projektpräsentation und im Fachgespräch geht es in der zwölften Episode der Shorts des IT-Berufe-Podcasts. Wenn dir nach Abgabe deiner Projektdokumentation Fehler auffallen, solltest du in der Projektpräsentation immer mit der korrigierten Version arbeiten und größere inhaltliche Fehler offen, aber knapp ansprechen. Triviale Formfehler wie Rechtschreibung oder Kommas musst du nicht thematisieren. Entscheidend ist ein professioneller Umgang: Fehler nicht leugnen oder ignorieren, sondern zeigen, was du daraus gelernt hast, wie du sie korrigiert hast und welche Folgen sie für das Projekt haben. Inhalt Umgang mit Fehlern nach Abgabe der Projektdokumentation Wenn dir nach der Abgabe deiner Projektdokumentation noch Fehler auffallen, gilt grundsätzlich: korrigieren statt ignorieren. Kleine formale Fehler musst du nicht extra erwähnen, größere inhaltliche Fehler solltest du dagegen offen und professionell behandeln. Grundidee Die Projektdokumentation, die Projektpräsentation und das Fachgespräch sind getrennte Prüfungsleistungen. Deshalb solltest du Fehler aus der Doku nicht einfach in die Präsentation übernehmen, nur weil die Doku schon abgegeben ist. In der Präsentation solltest du immer die korrigierte Fassung zeigen. Wichtig ist dabei: Fehler offen ansprechen, wenn sie relevant sind keinen großen Fokus auf die Fehler legen zeigen, wie du den Fehler erkannt und behoben hast deutlich machen, was du daraus gelernt hast Warum Fehler oft erst später auffallen Zwischen Abgabe der Dokumentation und Präsentation oder Fachgespräch liegen oft mehrere Wochen. In dieser Zeit bereitest du deine Präsentation vor und schaust dir Inhalte wie Kostenrechnung, Amortisation, Diagramme oder Projektplanung nochmal an. Dabei kann dir auffallen, dass etwas falsch gerechnet, unvollständig oder inhaltlich nicht mehr passend ist. Welche Fehler du ignorieren kannst Triviale formale Fehler musst du nicht ansprechen. Dazu gehören z.B.: Rechtschreibfehler fehlende Kommas falsche Seitenzahlen kleinere Verweisfehler Solche Kleinigkeiten führen nicht dazu, dass du durchfällst, und sind in der Präsentation nicht relevant. Welche Fehler du korrigieren und ggf. ansprechen solltest Relevant sind inhaltliche Fehler, also alles, was Auswirkungen auf das Projekt oder die Bewertung haben kann. Beispiele aus dem Text sind: Rechenfehler in der Kosten- oder Amortisationsrechnung Fehler in der Zeit- oder Ressourcenplanung vergessene Arbeitsstunden von Mitarbeitenden falsche oder nicht mehr passende technische Entscheidungen fehlende oder falsche Diagramme geplante, aber nicht umgesetzte Features Solche Fehler können zu einer anderen Einschätzung des Projekts führen. Deshalb solltest du sie professionell behandeln. Professioneller Umgang mit Fehlern Fehler zu machen ist normal, auch in echten IT-Projekten. Entscheidend ist nicht, dass nie etwas schiefläuft, sondern wie du damit umgehst. Genau das ist auch in der Prüfung relevant. Ein professioneller Umgang bedeutet: den Fehler erkennen einschätzen, wie schwerwiegend er ist überlegen, ob und wie er korrigiert werden kann die Auswirkungen auf das Projekt benennen erklären, wie du solche Fehler künftig vermeiden willst Das entspricht auch dem Verhalten im Berufsalltag. Wer merkt, dass sich ein Projekt später amortisiert oder länger dauert, darf das nicht verschweigen. Was in die Präsentation gehört In der Projektpräsentation solltest du nur dann auf einen Fehler eingehen, wenn er für die gezeigten Inhalte relevant ist. Kleine Auswirkungen Wenn sich durch einen Rechenfehler am Ergebnis praktisch nichts ändert, kannst du in der Präsentation einfach die korrigierte Version zeigen und den Fehler kurz mit einem Nebensatz erwähnen. Beispiel aus dem Text: Die Amortisation verschiebt sich nur um wenige Monate. Die Entscheidung für das Projekt bleibt trotzdem gleich. Dann reicht ein kurzer Hinweis, dass die Rechnung in der Doku leicht falsch war, das Endergebnis aber unverändert bleibt. Größere Auswirkungen Wenn ein Fehler deutliche Folgen hat, solltest du ihn klar benennen. Das kann z.B. sinnvoll sein, wenn: das Projekt sich gar nicht mehr amortisiert mehrere Features nicht umgesetzt wurden sich wesentliche Projektentscheidungen ändern Dann kann es sogar sinnvoll sein, dafür eine eigene Folie einzuplanen und nachvollziehbar zu erklären: was anders gelaufen ist als geplant warum das passiert ist welche Konsequenzen das hatte wie du damit umgegangen bist Was du nicht tun solltest Unprofessionell wäre es, einen bekannten Fehler absichtlich in der Präsentation zu wiederholen Fehler zu ignorieren Fehler zu leugnen lange auf Fehlern herumzureiten in der Präsentation Fehler anzusprechen, die dort gar nicht vorkommen Wenn ein fehlerhaftes Diagramm in der Präsentation gar nicht gezeigt wird, musst du es dort auch nicht thematisieren. Du sollst dich nicht unnötig schlechter machen. Vorbereitung auf das Fachgespräch Auch wenn du einen Fehler in der Präsentation nicht ansprichst, solltest du dich auf Fragen dazu im Fachgespräch vorbereiten. Mindestens ein Teil des Prüfungsausschusses hat die Doku gelesen und könnte den Fehler gefunden haben. Dann ist eine gute Reaktion z.B.: den Fehler bestätigen sagen, dass er inzwischen erkannt und korrigiert wurde die Auswirkungen kurz erklären So kann es sein, dass du in der Doku für den Fehler einen Punkt verlierst, im Fachgespräch aber einen positiven Eindruck hinterlässt, weil du professionell damit umgehst. Besonderheit beim Prüfungsausschuss Nicht alle Prüfenden haben deine Dokumentation zwingend gelesen. In vielen Ausschüssen wird die Arbeit aufgeteilt. Deshalb gilt für die Präsentation generell: geh nicht davon aus, dass alle deine Doku kennen erkläre dein Projekt so, dass auch neue Zuhörende folgen können verschwende keine Präsentationszeit mit langen Fehlererklärungen Gerade deshalb solltest du Fehler nur kurz und zielgerichtet ansprechen. Einfluss auf die Note Ein einzelner Fehler führt normalerweise nicht dazu, dass du durchfällst. Das Projekt wird als Gesamtleistung bewertet. Auch mit kleineren oder sogar größeren Fehlern kannst du noch eine gute oder sehr gute Note erreichen. Kritisch wird es eher dann, wenn du unprofessionell reagierst, also z.B.: Fehler bewusst verschweigst sie abstreitest Ausreden suchst Zentrale Kernaussage Wenn dir nach der Abgabe Fehler auffallen: bleib ruhig korrigiere inhaltliche Fehler zeige in der Präsentation immer die richtige Version sprich relevante Fehler kurz und offen an bereite dich auf Nachfragen im Fachgespräch vor zeige, was du daraus gelernt hast Vorbeugung vor der Abgabe Am besten ist es natürlich, Fehler schon vor der Abgabe zu vermeiden. Dafür kann es helfen, die Doku vor dem Einreichen noch einmal von anderen gegenlesen zu lassen, z.B. durch: dein:e Ausbilder:in andere Personen im Umfeld ein geeignetes KI-Tool für Rechtschreibung und Kommasetzung Das Optimum ist immer der Fehler, den du gar nicht erst machst. Links Permalink zu dieser Podcast-Episode RSS-Feed des Podcasts Transkription der gesamten Episode Automatisch erzeugte Transkription der Episode [0:20] Heute geht es um ein Thema, was wirklich sehr häufig gefragt wird, und zwar bezüglich der beiden Prüfungsleistungen, Projektdokumentation und Projektpräsentation und Fachgespräch. Wie soll ich damit umgehen, wenn ich in meiner Projektdokumentation Fehler finde, und zwar nachdem ich sie abgegeben habe? Soll ich das in der Projektpräsentation ansprechen? Soll ich die korrigieren? Soll ich darauf hinweisen? Soll ich das ignorieren? Soll ich es leugnen? Wie gehe ich mit Fehlern in der Doku um, nachdem die Doku abgegeben ist. Und es kommen dann ja noch zwei Prüfungsleistungen, nämlich die Präsentation und das Fachgespräch, wie gerade auch schon gesagt. Und es gibt ja verschiedene Möglichkeiten, wie ich mit diesen Fehlern umgehen kann. Und wie man am besten damit umgeht, ich würde erst mal sagen, wir fangen wieder mit dem Too Long den Read an. Ich würde sagen, immer korrigieren. Wenn dir Fehler auffallen, korrigiere sie im Nachhinein. Trivialitäten auf jeden Fall einfach stillschweigend sogar korrigieren. Und große Sachen explizit aber ansprechen, wenn sie irgendwie wichtig fürs Projekt sind und krass andere Entscheidungen zur Folge hätten oder das Projekt auf einmal drei Jahre länger braucht, um sich zu automatisieren oder Sonstiges. [1:23] Das würde ich auf jeden Fall ansprechen, aber keinen Fokus auf die Fehler legen. Projektpräsentation und Fachgespräch sind separate Prüfungsleistungen. Die haben zwar mit dem gleichen Thema zu tun, nämlich dein Projekt, aber die Projektpräsentation ist eine eigenständige Prüfungsleistung, unabhängig von der Doku. Also auch wenn du der Doku durchfällst, mal als Beispiel, könntest du eine Projektpräsentation bestehen, weil das sind halt zwei getrennte Prüfungsleistungen. Also, kurz gesagt, sprich die Fehler an, geh offen damit um, kommuniziere das und sag, dass du was gelernt hast, aber leg nicht den Fokus auf die Fehler. Und was ich jetzt genau damit meine, da gehen wir jetzt in den nächsten Minuten drauf ein. Fangen wir mal vorne an. Um was für Fehler soll es heute überhaupt gehen und warum kann und darf oder muss man die überhaupt korrigieren? Ich glaube, das Zweite ist einfacher zu beantworten. Zwischen der Abgabe der Dokumentation und der Projektpräsentation und Fachgespräch liegen bei vielen Prüflingen tatsächlich mehrere Wochen. Also jetzt mal nur als Beispiel. Ich nehme das gerade 2026 auf. Da war die Prüfung Ende April und zum Beispiel bei meiner IHK war dann eine Woche später die Abgabe. Also Anfang Mai musste man die Projektdokumentation abgeben. [2:28] Die Fachgespräche und Projektpräsentationen gehen aber bis Ende Juni. Das heißt, fast zwei Monate liegen eventuell dazwischen, zwischen

Um eine sinnvolle Prüfungsvorbereitung mit alten IHK-Prüfungen geht es in der elften Episode der Shorts des IT-Berufe-Podcasts. Ich empfehle dir, für die schriftliche Abschlussprüfung mit alten Prüfungen zu lernen und dabei mit den neuesten anzufangen. Wichtig ist aber, dass du immer den aktuell gültigen Prüfungskatalog prüfst, weil sich Inhalte durch Neuordnungen und Anpassungen verschieben oder wegfallen können. Für WiSo sind auch sehr alte Prüfungen sinnvoll, bei AP1 und AP2 musst du genauer schauen, welche alten Prüfungen thematisch noch zu deinem Prüfungsteil passen und dir idealerweise zusätzlich Feedback von deinem/deiner Ausbilder:in holen. Inhalt Alte Prüfungen sind grundsätzlich sinnvoll Ich halte es für sehr sinnvoll, dich mit alten Prüfungen auf die schriftliche Abschlussprüfung vorzubereiten. Das gilt sowohl für AP1 als auch für AP2. Am besten startest du aber immer mit den neuesten Prüfungen und arbeitest dich dann chronologisch rückwärts vor. Je aktueller eine Prüfung ist, desto höher ist die Wahrscheinlichkeit, dass sie noch gut zu den heutigen Anforderungen passt. Wichtig ist dabei eine Einschränkung: Du solltest alte Prüfungen nie blind durcharbeiten, sondern immer mit dem aktuell gültigen Prüfungskatalog abgleichen. Inhalte können sich durch die Neuordnung der IT-Berufe oder durch Änderungen am Prüfungskatalog verschieben, neu dazukommen oder wegfallen. Was sich seit der Neuordnung verändert hat Vor der Neuordnung 2020 gab es: eine Zwischenprüfung eine Abschlussprüfung mit: GA1 GA2 WiSo Alte Zwischenprüfung Die frühere Zwischenprüfung ist mit den heutigen Prüfungen praktisch nicht mehr vergleichbar. Sie bestand stark aus Multiple Choice und behandelte allgemeine IT-Themen für alle IT-Berufe. Dieser Prüfungsteil wurde ersatzlos gestrichen. Deshalb ist er für deine Vorbereitung heute nicht mehr relevant. WiSo Beim WiSo-Teil hat sich im Grunde nichts Wesentliches verändert. Die Themen und die Art der Fragen sind seit vielen Jahren ähnlich geblieben. Es geht dort um allgemeine wirtschaftliche und soziale Inhalte wie: Wirtschaft, Rentabilität Märkte, Angebot und Nachfrage Arbeitsverträge Gewerkschaften, Streik, Betriebsrat Deshalb kannst du für WiSo auch sehr alte Prüfungen verwenden, sogar viele Jahre zurück. Als Untergrenze empfehle ich mindestens die letzten fünf Jahre, also bei zwei Terminen pro Jahr etwa zehn Prüfungen. Wie alte und neue Prüfungsteile zusammenhängen Für die fachlichen Teile gibt es grobe Entsprechungen zwischen alt und neu: alte GA1 entspricht am ehesten der heutigen AP2 alte GA2 entspricht am ehesten der heutigen AP1 Der Hintergrund: Die GA1 war berufsspezifisch, ähnlich wie die heutige AP2. Die GA2 war für alle IT-Berufe gleich und damit eher mit der heutigen AP1 vergleichbar. Warum du immer den aktuellen Prüfungskatalog brauchst Es gab nicht nur 2020 eine große Neuordnung, sondern auch weitere Änderungen: 2018: kleinere Reform mit Datenschutz und Datensicherheit in der Prüfung 2020: große Überarbeitung der IT-Berufe 2025: Anpassung der Prüfungskataloge Dadurch kann es passieren, dass alte Prüfungen Themen enthalten, die heute nicht mehr geprüft werden, oder umgekehrt, dass heute Themen relevant sind, die in älteren Prüfungen noch gar nicht vorkamen. Ein Beispiel dafür ist SQL: In der AP1 wurde SQL mit dem neuen Prüfungskatalog gestrichen. In der AP2 ist SQL heute relevant. Deshalb kann es sein, dass du für bestimmte Berufe oder Prüfungsteile passende SQL-Aufgaben nicht direkt in alten AP2-Prüfungen findest, sondern eher in älteren AP1-Prüfungen oder in AP2-Prüfungen anderer IT-Berufe, zum Beispiel der Anwendungsentwicklung. Ein weiteres Beispiel ist RAID, das in der AP1 ebenfalls nicht mehr relevant ist, aber in älteren Prüfungen noch häufig vorkommt. So gehst du bei alten Prüfungen sinnvoll vor Ich empfehle dir dieses Vorgehen: Prüfungskatalog besorgen Dort steht, welche Themen aktuell für AP1 oder AP2 in deinem Beruf relevant sind. Mit den neuesten Prüfungen anfangen Zuerst den Prüfungsteil bearbeiten, auf den du dich konkret vorbereitest. Dann chronologisch rückwärts arbeiten So lange, bis du bei den Prüfungen ab 2020 angekommen bist. Danach Prüfungstrainer nutzen Zum Beispiel die Prüfungstrainer aus dem U-Form-Verlag mit prüfungsnahen Aufgaben und Lösungen. Erst danach sehr alte Prüfungen ergänzend anschauen Für AP2 eher alte GA1 Für AP1 eher alte GA2 Wichtig ist dabei immer: Wenn ein Thema heute neu in einem Prüfungsteil ist, kannst du auch in anderen alten Prüfungen nach passenden Aufgaben suchen, selbst wenn sie ursprünglich für einen anderen Prüfungsteil oder einen anderen IT-Beruf gedacht waren. Lass dich von alten Aufgaben nicht verunsichern Wenn du in älteren oder auch noch relativ neuen Prüfungen Aufgaben zu Themen findest, die laut aktuellem Prüfungskatalog nicht mehr drankommen sollen, ist das kein Widerspruch. Der Grund ist einfach, dass diese Prüfungen noch auf älteren Regelungen basieren. Deshalb gilt: Nicht jede alte Aufgabe ist heute noch relevant. Nicht jedes heute relevante Thema ist in alten Prüfungen sofort leicht zu finden. Maßgeblich ist immer der aktuelle Prüfungskatalog. Wenn dort ein Thema nicht mehr enthalten ist, musst du es bei knapper Zeit nicht gezielt für diesen Prüfungsteil lernen. Es ist natürlich trotzdem nicht falsch, solche Inhalte grundsätzlich zu können. Lösungen nie nur stumpf vergleichen Wenn du mit alten Prüfungen lernst, solltest du deine Antworten nicht nur mit den Lösungshinweisen vergleichen. Dabei gilt: Es gibt meist keine echten Musterlösungen, sondern nur Lösungsvorschläge oder Lösungshinweise. Gerade bei offenen Aufgaben kann es mehrere richtige Wege geben. Das betrifft zum Beispiel: Datenbankmodellierung Pseudocode andere Aufgaben mit Transferleistung Deshalb musst du nicht verzweifeln, wenn deine Lösung anders aussieht als auf dem Lösungbogen. AP1 und AP2 werden von Menschen korrigiert, die dabei einen Bewertungsspielraum haben. Feedback ist ein wichtiger Teil der Vorbereitung Ich finde es sinnvoll, alte Prüfungen gemeinsam mit deinem/deiner Ausbilder:in oder einer anderen fachkundigen Person durchzusprechen. So kannst du besser einschätzen: ob deine Lösung trotzdem Punkte bekommen würde wo deine Denkfehler liegen ob eine alternative Lösung fachlich in Ordnung ist Besonders hilfreich ist das bei offenen Aufgaben, bei denen nicht nur eine einzige Formulierung korrekt sein kann. Im Ausbildungsalltag mit meinen eigenen Azubis wird etwa jeden Monat eine alte Prüfung bearbeitet und danach mit einem/einer Ausbildungsbeauftragten besprochen. Fazit Ja, du kannst auch mit ganz alten Prüfungen lernen. Ich würde aber nicht damit anfangen. Mein Vorschlag ist: zuerst die neuesten Prüfungen dann passende Prüfungstrainer danach bei Bedarf ältere Prüfungen und sehr alte Prüfungen nur ergänzend und gezielt Für WiSo sind auch sehr alte Prüfungen gut nutzbar. Für AP1 und AP2 musst du dagegen genauer prüfen, welche Aufgaben heute noch zu deinem Prüfungskatalog passen. Alte Prüfungen sind ein wichtiger Bestandteil der Vorbereitung, am sinnvollsten zusammen mit Feedback und ergänzt durch eigenes Lesen, Umsetzen, Programmieren oder Administrieren. Links Permalink zu dieser Podcast-Episode RSS-Feed des Podcasts Vorbereitung auf die schriftliche Abschlussprüfung Fachinformatiker Anwendungsentwicklung: Prüfungstrainer Abschlussprüfung Teil 2 Fachinformatiker Systemintegration: Prüfungstrainer Abschlussprüfung Teil 2 Transkription der gesamten Episode Automatisch erzeugte Transkription der Episode [0:20] Heute geht es um ein Thema, was regelmäßig inzwischen viermal im Jahr immer wieder angefragt wird. Und zwar, wie bereite ich mich am besten auf die schriftliche Abschlussprüfung vor? Warum viermal im Jahr? Naja, es gibt vier Termine im Jahr. Es gibt zweimal die AP1 im Frühjahr und im Herbst und zweimal die AP2 im Sommer und im Winter. Und immer sind die Fragen dieselben. Wie bereite ich mich darauf vor? Was kommt dran? Etc. Ich habe, glaube ich, als allererste Folge oder eine meiner allerersten Folgen in diesem Podcast schon Tipps zur Prüfungsverwaltung gegeben und habe ich vor kurzem auch nochmal aktualisiert. Aber heute geht es um eine ganz spezielle Frage in diesem Zusammenhang. Und zwar kann, soll, muss ich auch mit älteren Prüfungen mich vorbereiten? Oder soll ich nur die neuesten Prüfungen durchgehen? Und ja, da möchte ich auch mal drauf eingehen. Kurz vorweg schon mal, guck dir am besten so viele alte Prüfungen wie möglich an. Das kann auf jeden Fall nicht schaden. Aber mit einer kleinen Einschränkung bedenke immer, was der aktuelle Umfang an Themen für deine konkrete Prüfung ist, die gerade vor dir steht, weil der kann sich ändern. [1:23] So, und jetzt tun wir mal ein bisschen weiter aus. Vor der Neuordnung der IT-Berufe 2020 gab es eine Zwischenprüfung und eine schriftliche Abschlussprüfung. Die Zwischenprüfung, das sage ich schon mal gleich vorweg, die kannst du eigentlich mit keiner der heutigen Prüfungen mehr vergleichen. Das war ganz viel Multiple Choice und einmal rundum um alle möglichen IT-Sachen für alle Berufe, auch gleich für alle IT-Berufe. Und der Prüfungsteil ist tatsächlich einfach ersatzlos gestrichen und den brauchst du dir tatsächlich auch nicht mehr angucken. Das kannst du ad acta legen, das interessiert keinen Menschen mehr. [1:53] Aber dann gab es noch die eigentliche Abschlussprüfung früher, war ja nicht aufgeteilt in 1 und 2, sondern eben die Zwischenprüfung und dann kam die Abschlussprüfung und da gab es zwei Teile. Einmal die sogenannten ganzheitlichen Aufgaben 1 und ganzheitliche Aufgaben 2, GA1 und GA2 oder GH1, GH2 abgekürzt. Und den Visoteil. Und den Visoteil, den Spoiler ich schon mal, der ist, da kannst du dir eigentlich alle Prüfungen auc

Um die sinnvolle Platzierung von Artefakten in der Projektdokumentation geht es in der zehnten Episode der Shorts des IT-Berufe-Podcasts. Inhalt Ich empfehle dir für die Projektdokumentation als klare Daumenregel, Artefakte wie Diagramme, Tabellen, Code, Screenshots oder Berechnungen in den Anhang zu packen – besonders dann, wenn sie größer als eine halbe Seite sind. Im Fließtext sollte stattdessen stehen, warum du ein Artefakt erstellt hast, wie es dir im Projekt geholfen hat und was du daraus abgeleitet hast. Nur kleine, direkt erklärungsbedürftige Artefakte können aus Gründen der Lesbarkeit ausnahmsweise in den Fließtext. Was ich mit Artefakten meine Mit Artefakten sind alle Bestandteile der Projektdokumentation gemeint, die kein eigentlicher Fließtext sind. Dazu zählen zum Beispiel: Diagramme wie UML-Diagramme oder ER-Modelle Tabellen, etwa für Kosten oder Zeitplanung Code Netzwerkpläne Testprotokolle Berechnungen und Formeln Screenshots und Fotos Zentrale Daumenregel Meine Empfehlung ist klar: Alle Artefakte gehören grundsätzlich in den Anhang. Alles, was größer als eine halbe Seite ist, sollte auf jeden Fall in den Anhang. Nur wenige Ausnahmen sprechen dafür, ein Artefakt direkt im Fließtext zu platzieren. Warum Artefakte besser in den Anhang gehören Der wichtigste Grund ist die begrenzte Seitenzahl für den Fließtext. Viele IHKs machen dafür klare Vorgaben, zum Beispiel 15 Seiten Fließtext und 25 Seiten Anhang. Diese Vorgaben unterscheiden sich aber je nach IHK teilweise deutlich. Wichtig ist deshalb: Prüfe immer die konkreten Vorgaben deiner IHK. Verlasse dich nicht pauschal auf Angaben aus dem Internet. Wenn du Artefakte in den Fließtext einbaust, verbrauchen sie dort Platz. Dadurch bleibt weniger Raum für erklärenden Inhalt, der in der Bewertung oft entscheidend ist. Eine Seite Klassendiagramm im Fließtext ist dann eben keine Seite Fließtext mehr. Seitenzahl ist nicht das eigentliche Problem Entscheidend ist nicht, ob am Ende 14 oder 15 Seiten dort stehen. Entscheidend ist, ob wichtige Inhalte fehlen. Wenn zum Beispiel in einem Projekt ein bestimmtes Artefakt sinnvoll oder zu erwarten ist, dann fehlt ohne dieses Artefakt möglicherweise ein relevanter Inhalt. Umgekehrt hilft es auch nicht, die maximale Seitenzahl auszuschöpfen, wenn dabei inhaltlich etwas Wichtiges fehlt. Die Seitenzahl ist also nur ein Rahmen. Bewertet werden am Ende die Inhalte, nicht bloß die Zahl auf der letzten Seite. Ausnahme: Lesbarkeit Der wichtigste Grund, ein Artefakt doch im Fließtext zu platzieren, ist die Lesbarkeit. Das kann sinnvoll sein, wenn: ein Artefakt sehr erklärungsbedürftig ist der zugehörige Text direkt daneben stehen sollte ständiges Blättern oder Springen zwischen Text und Anhang das Verständnis erschwert Beispiele dafür können sein: eine kurze, erklärungsintensive Code-Stelle eine kleine Berechnung oder Formel eine kompakte Kostenberechnung eine grobe Zeitplanung eine Amortisationsrechnung Dabei bleibt die zweite Daumenregel bestehen: Ist das Artefakt größer als eine halbe Seite, gehört es trotzdem in den Anhang. Denn wenn Erklärung und Artefakt ohnehin nicht mehr gemeinsam auf eine Seite passen, geht der Vorteil für die Lesbarkeit wieder verloren. Artefakte nicht als Seitenfüller verwenden Artefakte sollten nicht dazu dienen, den Fließtext künstlich aufzublähen, wenn dir sonst Inhalt fehlt. Wenn große oder unpassende Artefakte ohne echten Grund im Fließtext stehen, kann das bei der Bewertung als Hinweis gesehen werden, dass dort eigentlich zu wenig sinnvoller Textinhalt vorhanden ist. Solche Artefakte werden inhaltlich nicht als Ersatz für fehlende Erklärungen gewertet. Wichtig dabei: Es gibt nicht automatisch Punktabzug wegen einer bestimmten Seitenzahl. Punktabzug entsteht dann, wenn dadurch erkennbare inhaltliche Lücken bleiben. Artefakte haben einen Zweck Eine Projektdokumentation sollte nicht aus einer bloßen Sammlung von Artefakten bestehen. Nicht ausreichend ist zum Beispiel: Überschrift ein Satz wie "Ich habe ein UML-Diagramm erstellt, siehe Anhang" sonst keine weitere Erklärung Artefakte haben keinen Selbstzweck. Sie sollen zeigen, dass du methodisch gearbeitet hast und dir vor der Umsetzung Gedanken gemacht hast. Beispiele: In der Anwendungsentwicklung helfen Klassendiagramme, ER-Modelle oder Architekturskizzen dabei, die Struktur vor der Implementierung zu planen. In der Systemintegration helfen Netzwerkpläne oder Sicherheitsüberlegungen dabei, Anforderungen und Rahmenbedingungen sauber zu analysieren. Artefakte sollen also nicht nur für die Prüfung da sein, sondern einen praktischen Nutzen im Projekt haben. Was in den Fließtext gehört Im Fließtext sollte stehen: warum du ein Artefakt erstellt hast wie du dabei vorgegangen bist welche Besonderheiten dir dabei aufgefallen sind wie dir das Artefakt im weiteren Verlauf geholfen hat was du darauf aufbauend später gemacht hast Ein gutes Beispiel wäre nicht nur zu schreiben, dass ein Klassendiagramm existiert, sondern zu beschreiben: welche Klassen notwendig waren welche Beziehungen oder Abstraktionen sich ergeben haben welche Erkenntnisse daraus entstanden sind wie das Diagramm später bei der Implementierung geholfen hat Das Artefakt selbst kommt dann in den Anhang, der Kontext und die Einordnung gehören in den Fließtext. Fazit Die Kernaussage ist: Artefakte in den Anhang Erklärungen, Einordnung und Nutzen in den Fließtext Ausnahmen im Fließtext sind nur dann sinnvoll, wenn kleine Artefakte direkt zum Verständnis beitragen. Für fast alles andere gilt: Anhang. So nutzt du sowohl den Fließtext als auch den Anhang sinnvoll aus und zeigst nicht nur Ergebnisse, sondern auch dein methodisches Vorgehen. Links Permalink zu dieser Podcast-Episode RSS-Feed des Podcasts Transkription der gesamten Episode Automatisch erzeugte Transkription der Episode [0:20] Heute geht es mal um eines meiner Lieblingsthemen, wenn ich wieder Projektdokumentation lese und bewerten darf. Und zwar um die Platzierung von Artefakten in der Projektdokumentation. Diesen Begriff Artefakt, den benutze ich ganz häufig im Blog, im Podcast, in meinen Videos. Was ist damit gemeint? Kurz zum Einstieg. Ich meine mit Artefakt alles, was in der Dokumentation oder in deiner Präsentation später auch, was kein Fließtext ist. Also Beispiel Projektdokumentation, irgendwelche Diagramme, UML-Sachen, ER-Modelle, Amortisationsrechnung, wenn du die grafisch machst, aber auch Tabellen, zum Beispiel Kostenaufstellung oder deine Zeitplanung. Code natürlich, wenn du Anwendungsentwicklung machst, irgendwelche Pläne, Netzwerkpläne oder Sonstiges oder ein Testprotokoll oder so. Oder auch wenn du Berechnungen machst, irgendwelche Formeln oder Sachen, die nacheinander berechnet werden, zum Beispiel bei der Amortisationsrechnung. Und selbstverständlich auch Screenshots, wenn du Fotos machst aus der echten Welt, solche Dinge, das sind für mich alles Artefakte. Also Dinge, die kein Text sind, wobei, ja, Code ist Text, okay. Aber ich glaube, du verstehst, worauf ich hinaus will. Fließtext im Verhältnis zu alles andere sind Artefakte. Und ich mache es gerne zum Einstieg nochmal, wie in anderen Episoden auch, so ein Too Long Didn’t Read oder Didn’t Here in diesem Fall. Meine Empfehlung ist, pack alle Artefakte in den Anhang. Es gibt wenig Gründe dafür, Artefakte in deinen Fließtext zu packen. Also du schreibst einen Satz, machst dann ein Artefakt da rein und schreibst dann weiter. [1:48] Daumenregel sollte sein, alles in den Anhang. Und absolute Daumenregel aus meiner Sicht ist, alles was größer ist als eine halbe Seite, auf jeden Fall in den Anhang. So und jetzt gibt es vielleicht ein, zwei kleine Ausnahmen, wo man Artefakte auch in den Fließtext packen sollte oder darf oder vielleicht sogar muss. Da gehen wir gleich nochmal drauf ein. Aber als Daumenregel kannst du schon mal mitnehmen, alle Artefakte in den Anhang, insbesondere wenn sie größer sind als eine halbe Seite. [2:13] So, jetzt gehen wir mal die Details da durch. Warum ist das so? Warum ist das sinnvoll? Also, vielleicht vorweg, die meisten IHK’n machen irgendwelche Vorgaben für deine Projektdokumentation, was die Seitenzahl angeht. Und das sind meistens Maximalforgaben, also zum Beispiel maximal 15 Seiten Fließtext und 25 Seiten Anhang. So ist es zum Beispiel bei der IHK Oldenburg, wo ich beschäftigt bin. Ganz wichtig vorweg, guck dir unbedingt die Vorgaben deiner IHK an. Es gibt nämlich 79 verschiedene in Deutschland und die machen im Zweifel alle unterschiedliche Vorgaben. Also orientier dich nicht an irgendwas, was du im Internet gehört oder gelesen hast, sondern frag bei deiner IHK nach, wo du deine Note nachher bekommst, was die Vorgaben sind. Ich gehe jetzt mal einfach davon aus, dass es 15 Seiten für Fließdecks sind und 25 für Anhang. So ist es bei uns. Aber das kann stark abweichen. Ich habe teilweise Vorgaben gesehen bis 10 Seiten runter plus nochmal 5 im Anhang oder so. Also wirklich deutlich weniger. Es gibt aber auch nach oben Abweichungen. Also guck einfach nach, was gilt für dich und dann orientierst du dich an diesen Zahlen. Ich gehe jetzt mal von den 15 Seiten aus und dann ist es üblicherweise so, dass du deine Seitenzahl maximal ausreizen möchtest. Dafür habe ich auch eine eigene Episode, einen kleinen Short aufgenommen, verlinke ich auch nochmal in den Shownotes, warum ich dann empfehlen würde, die Seitenzahl auszufüllen. Kurz gesagt, was ist, wenn du nicht alles ausfüllst? Kriegst du eine schlechte Note? Ja, dann hast du deine Chancen, die du hättest, halt nicht genutzt. Du hast zu wenig Inhalt geliefert, kriegst dafür einen Punktabzug. Blöd, ja? Also versuch die Seitenzahl auszunutzen und so gut es geht, alles mit sinnvollen Inhalten zu füllen. [3:40] Und dann solltest du, wenn du sinnvolle Inhalte hast, sowas wie Lastenpflichtenheft, UML-Diagramme u

Um eine sinnvolle Anzahl der Seiten der Projektdokumentation geht es in der neunten Episode der Shorts des IT-Berufe-Podcasts. Ich würde dir bzgl. der Anzahl der Seiten deiner Projektdokumentation raten, dich immer zuerst an den konkreten Vorgaben deiner IHK zu orientieren, weil Umfang und Regeln je nach IHK unterschiedlich sein können. Die vorgegebene Seitenzahl ist in der Regel eine Obergrenze, die du nicht überschreiten solltest, gleichzeitig solltest du den verfügbaren Platz möglichst mit sinnvollen Inhalten nutzen, weil zu wenig Text meist nicht wegen der Seitenzahl, sondern wegen fehlender Inhalte zum Problem wird. Für mich gilt deshalb: nicht künstlich aufblasen, aber Fließtext und Anhang so gut wie möglich mit bewertbaren, fachlich passenden Inhalten füllen. Inhalt TL;DR: Schreib exakt so viele Seiten in deiner Projektdokumentation, wie es deine IHK erlaubt, und nutze den maximalen Umfang möglichst sinnvoll aus, ohne ihn zu überschreiten. Erst auf die Vorgaben deiner IHK schauen In Deutschland gibt es viele verschiedene IHKen und sie können bei der Projektdokumentation unterschiedliche Vorgaben haben. Deshalb solltest du dich nicht auf Aussagen aus Social Media oder aus "dem Internet" verlassen, sondern immer die Unterlagen deiner eigenen IHK prüfen. Typische Unterschiede können sein: erlaubte Seitenzahl im Fließtext Regelungen zum Anhang Umgang mit Verzeichnissen Vorgaben zu Schriftgröße und Schriftart Pflicht zu Deckblatt oder bestimmten Bestandteilen Mein Rat ist deshalb: Schau in die Merkblätter, Handreichungen oder Vorgaben deiner IHK und orientiere dich genau daran. Die Seitenzahl ist normalerweise eine Maximalvorgabe Die vorgegebene Seitenzahl meist eine Obergrenze. Es geht also nicht darum, die Seiten zwanghaft vollzumachen, sondern darum, nicht darüber zu liegen. Der Hintergrund dafür ist aus meiner Sicht vor allem organisatorisch und fair: Prüfende müssen viele Dokumentationen in begrenzter Zeit lesen umfangreiche Dokumentationen sind in der Praxis schwer zu bewerten alle Prüflinge sollen unter vergleichbaren Bedingungen bewertet werden Als typischen Rahmen gibt es meist 10 bis 20 Seiten Fließtext, je nach IHK. Oft gibt es zusätzlich eine eigene Begrenzung für den Anhang. Ein Beispiel aus Oldenburg: 15 Seiten Fließtext maximal 25 Seiten Anhang maximal Verzeichnisse und bestimmte formale Bestandteile zählen dabei nicht mit Zu viele Seiten können zu Abzügen führen Wenn du die maximale Seitenzahl überschreitest, hast du die Vorgaben nicht eingehalten. Ich vergleiche das gerne mit einem Budget, das überschritten wird: Wenn 15 Seiten erlaubt sind, dann sind 16 eben formal zu viel. Ich sage aber auch: wegen einer kleinen Überschreitung fällt man nicht automatisch durch die Folgen hängen von Bewertungskriterien und dem jeweiligen Prüfungsausschuss ab formale Fehler führen eher zu kleineren Abzügen als zu einem kompletten Duchfallen Trotzdem bleibt mein Hinweis eindeutig: Überschreite die erlaubte Seitenzahl nicht. Zu wenige Seiten sind nicht direkt das Problem Ich betone hier nochmal, dass niemand allein deshalb Punkte abzieht, weil du weniger Seiten abgegeben hast als maximal erlaubt. Eine Dokumentation mit weniger Seiten ist formal erst einmal in Ordnung. Das eigentliche Problem ist für mich etwas anderes: Wenn du deutlich weniger schreibst, fehlen oft wichtige Inhalte. Der Punktabzug kommt dann nicht wegen der Seitenzahl, sondern wegen nicht dokumentierter Inhalte. Mein Beispiel dazu: Wenn ich bei einem Softwareprojekt ein Klassendiagramm erwarten würde und es fehlt, dann ziehe ich dafür Punkte ab. Nicht, weil noch freie Seiten übrig waren, sondern weil ein inhaltlich sinnvoller Bestandteil fehlt. Mein praktischer Rat: Nutze den verfügbaren Platz aus Ich empfehle dir, die erlaubte Seitenzahl möglichst vollständig zu nutzen, weil die Wahrscheinlichkeit hoch ist, dass sonst etwas Relevantes fehlt. Das heißt aber ausdrücklich nicht, dass du die Seiten mit beliebigem Material oder KI-generiertem Fülltext aufblasen sollst. Wichtig ist mir dabei: keine inhaltsleeren Wiederholungen keine künstlich verlängerten Beschreibungen keine sinnlosen Diagramme ohne Aussagekraft stattdessen nur Inhalte, die einen fachlichen Mehrwert haben und bewertet werden können Wie ich auf Seitenzahl und Inhalt schaue Beim Lesen von Projektdokumentationen betrachte ich Artefakte im Fließtext gedanklich anders als reinen Fließtext. Dazu zähle ich zum Beispiel: Abbildungen Tabellen Diagramme Codeschnipsel Berechnungen Wenn mitten im Fließtext viele solcher Elemente stehen, ist das für mich ein Hinweis darauf, dass der eigentliche beschreibende Text kürzer ausfällt. Das führt nicht automatisch zu einem Abzug, aber es kann ein Indiz sein, dass Inhalte eventuell zu knapp dargestellt wurden. Entscheidend bleibt für mich immer der Inhalt, nicht die nackte Seitenzahl. Was du in eine Projektdokumentation aufnehmen könntest Hier kommt eine ganze Reihe von Inhalten, die in einem typischen Projekt der Fachinformatiker:innen, besonders in der Anwendungsentwicklung, vorkommen können. Vieles davon gilt auch für andere IT-Berufe. Anforderungen Anforderungsermittlung Lastenheft Pflichtenheft User Storys Product Backlog Architektur und technische Modelle Architekturskizzen UML-Diagramme Klassendiagramme Sequenzdiagramme Zustandsdiagramme Komponentendiagramme Deployment-Diagramme Infrastruktur und Systemdarstellung Netzwerkpläne Server-Erreichbarkeit Ports und technische Zusammenhänge Datenmodellierung und Schnittstellen ER-Modelle relationale Tabellenmodelle JSON-Strukturen OpenAPI-Beschreibungen bei REST-APIs Prozesse und Abläufe dokumentierte oder optimierte Prozesse Modellierung mit BPMN EPK Aktivitätsdiagramme Umsetzungsnachweise Quellcode aus Produktivcode oder Testcode Screenshots Konfigurationsdateien Fotos von umgesetzten Arbeiten Projektorganisation Vorgehensmodell wie Scrum, Wasserfall oder Kanban Beschreibung des Entwicklungsprozesses Ticket-System Code-Review Zusammenarbeit mit anderen Beteiligten organisatorische Abläufe Planung und Wirtschaftlichkeit Zeitplanung für die 40 bzw. 80 Stunden Ressourcenplanung detaillierte Tabellen Kostenkalkulation Amortisationsrechnung Gegenüberstellung von Kosten und Einsparpotenzial Mit dieser Liste will ich zeigen, dass bei einem normalen Projekt schnell viele sinnvolle Inhalte zusammenkommen können und 15 Seiten deshalb durchaus knapp werden können. Meine abschließende Motivation für dich Ich gebe dir am Ende noch einen Gedanken mit: Wenn du eine schlechte Note bekommst oder sogar durchfällst, obwohl du noch freie Seiten gehabt hättest, wirst du dich möglicherweise fragen, ob zusätzliche sinnvolle Inhalte den Unterschied gemacht hätten. Deshalb mein Fazit: halte die Maximalvorgabe deiner IHK ein überschreite sie nicht nutze den verfügbaren Platz aber möglichst aus fülle ihn nur mit sinnvollen, bewertbaren Inhalten Für mich ist genau das der sinnvolle Weg, damit deine Projektdokumentation zeigt, was du in deiner Ausbildung gelernt hast und was du im Projekt tatsächlich geleistet hast. Links Permalink zu dieser Podcast-Episode RSS-Feed des Podcasts Inhalte der Projektdokumentation Gliederung der Projektdokumentation (Teil 1) Transkription der gesamten Episode Automatisch erzeugte Transkription der Episode [0:20] Heute geht es um ein Thema, was immer wieder für Aufsehen sorgt oder Aufregung auf, vor allem im Internet, gerade bei TikTok, unter meinen letzten Videos, die ich gerade gepostet habe, während ich das hier aufnehme. Und zwar zum Thema Seitenzahlen in der Projektdokumentation bei dem Abschlussprojekt der IT-Berufe. Und ja, Kernfrage, die ich heute beantworten will, ist, wie viele Seiten sollte meine Projektdokumentation haben? Also vor allem Fließtext, aber auch Anhang, wie viele Seiten sind da sinnvoll? Und ich mache mal so ein Too-Long-Din't-Read zum Einstieg. Wenn du nicht weiterhören willst als hier, schreib einfach genauso viele Seiten voll, wie deine IHK dir erlaubt. Das war's. Und jetzt kommen wir kurze Erklärungen, warum das so ist. Fangen wir vielleicht mal ganz vorne an. Deine IHK erlaubt dir was? Hä? Ja, denn wir erinnern uns, wir haben in Deutschland 79 verschiedene IHKen. Und die machen für ihre Abschlussprojekte, für die IT-Brufe alle eventuell unterschiedliche Vorgaben. Einige machen auch keine Vorgaben oder haben einfach nichts online oder was auch immer, machen stillschweigend irgendwelche Vorgaben. Aber erstmal ist Fakt, wir haben verschiedene IHK'en und die machen potenziell unterschiedliche Vorgaben, was den Umfang einer Projektdokumentation angeht. Das heißt von, ich glaube, 10 bis 20 Seiten Fließtext habe ich schon verschiedene Vorgaben gesehen. [1:34] Einige nehmen den Anhang mit dazu, andere nicht. Verzeichnen es raus oder doch nicht. Und es gibt überall die Möglichkeit für jede IHK, das individuell festzulegen. Es ist nicht deutschlandweit standardmäßig überall gleich. Das schon mal vorweg. Wie bei ganz vielen anderen Sachen auch übrigens zur Abschlusspräsentation und Projektdokumentation. Immer erstmal gucken, was die eigene IHK vorgibt. Weil das kann teilweise sehr krass unterschiedlich sein zu irgendwas, was du irgendwo anders im Internet liest oder gehört hast. Also guck immer, was deine IHK dir vorgibt. Daran musst du dich orientieren und nicht an irgendwas, was du irgendwo mal gehört hast bei TikTok, Instagram oder YouTube. Ja, deine IHK vergibt, nein, die IHK gibt dir nicht die Note, der Prüfungsausschuss gibt dir die Note, aber die orientieren sich natürlich an den Vorgaben der jeweiligen IHK. Also bitte erstmal darauf gucken. Und im einfachsten Fall guckst du auf der Website deine IHK, da gibt es normalerweise Merkblätter, Handreichungen, Vorgaben, was auch immer, zur Projektarbeit in den IT-Berufen. Ja, es gibt Projektarbeiten auch in anderen Berufen....

Um Stakeholder für deine IHK-Projektarbeit geht es in der achten Episode der Shorts des IT-Berufe-Podcasts. Ich zeige dir in diesem Podcast-Short, warum Stakeholder für jedes IHK-Abschlussprojekt zentral sind: Von ihnen kommen die Anforderungen, an denen sich später die Qualität deines Projekts misst. Dabei solltest du nicht nur an Kund:innen und Benutzer:innen denken, sondern auch zum Beispiel an Projektleitung, Betrieb, Support, Datenschutz, Gesetzgeber, Sicherheitsverantwortliche, Management, externe Dienstleistende oder technische Rahmenbedingungen. Ich empfehle dir, alle relevanten Stakeholder systematisch zu sammeln, ihre Anforderungen zu dokumentieren und zu priorisieren, damit dein Projekt nicht an übersehenen Anforderungen scheitert. Stakeholder und Anforderungen im IHK-Abschlussprojekt Ich erkläre dir, warum die Stakeholder-Analyse in praktisch jedem Abschlussprojekt für die IHK-Prüfung wichtig ist. Egal ob du in der Anwendungsentwicklung, Systemintegration oder in einem kaufmännischen IT-Beruf arbeitest: Du brauchst eine Anforderungsanalyse. Dabei geht es darum, herauszufinden, wer was von deinem Projekt erwartet und welche Anforderungen daraus entstehen. Die Anforderungen musst du aufnehmen, dokumentieren, priorisieren und konkretisieren. Sie sind entscheidend für den Projekterfolg, denn Qualität bedeutet: Grad der Übereinstimmung mit den Anforderungen. Wenn Anforderungen fehlen, unklar sind oder übersehen wurden, kannst du am Ende nicht sicher sagen, ob dein Projekt wirklich erfolgreich ist. Was Stakeholder sind Ich fasse Stakeholder als alle Personen, Rollen, Institutionen oder auch Rahmenbedingungen auf, die: Interesse an deinem Projekt haben, Einfluss auf dein Projekt haben, oder von deinem Projekt betroffen sind. Wichtig ist: Nicht alle denkbaren Stakeholder sind in jedem Projekt relevant. Die Liste soll dir helfen, mögliche Stakeholder nicht zu vergessen. Warum Stakeholder oft übersehen werden Ich beobachte häufig, dass Prüflinge nur an folgende Stakeholder denken: Kund:innen beziehungsweise Auftraggeber:innen Endbenutzer:innen Dabei werden viele weitere Stakeholder vergessen, obwohl sie ebenfalls konkrete und teilweise harte Anforderungen an das Projekt haben. Wenn du nur einzelne Stakeholder berücksichtigst, kann dein Projekt später scheitern, weil wichtige Anforderungen fehlen. Mögliche Stakeholder und ihre typischen Anforderungen Kund:innen oder Auftraggeber:innen Diese Stakeholder bezahlen das Projekt oder geben es in Auftrag. Ihre typischen Interessen sind: Einhaltung des Budgets Einhaltung von Terminen Erreichen der Business-Ziele Kund:innen sind nicht automatisch auch die Menschen, die das Ergebnis später benutzen. Endbenutzer:innen Das sind die Personen, die mit der Software oder dem System tatsächlich arbeiten. Ihre Anforderungen können ganz anders sein als die der Kund:innen, zum Beispiel: einfache Bedienung gute Performance Zuverlässigkeit Das gilt nicht nur für Software, sondern auch für Systeme in der Systemintegration. Projektleitung Auch die Projektleitung ist ein Stakeholder. In deinem IHK-Projekt kannst das auch du selbst sein. Mögliche Anforderungen sind: Planungssicherheit Risikominimierung Reporting Gerade im Prüfungsprojekt ist Planungssicherheit wichtig, weil du nur eine begrenzte Stundenzahl hast. Entwickler:innen beziehungsweise Administrator:innen Die Personen, die das System später weiterentwickeln oder betreiben, haben ebenfalls Anforderungen. Beispiele sind: wartbarer Code stabile Systeme gute Testbarkeit definierte Deployment-Prozesse stabile APIs eventuell Anforderungen an UX, UI oder Barrierefreiheit Für die Systemintegration können zusätzlich wichtig sein: hohe Verfügbarkeit Skalierbarkeit Monitoring Alerts IT-Betrieb und Support Dieser Stakeholder wird oft vergessen, obwohl das System nach der Einführung meist über längere Zeit betrieben wird. Typische Anforderungen sind: Wartbarkeit im Betrieb Logging Dokumentation klare Prozesse für Fehlerfälle Datenschutz und Compliance Sobald dein Projekt in einem regulierten Umfeld stattfindet, können daraus verbindliche Anforderungen entstehen. Beispiele sind: DSGVO-Konformität Datensparsamkeit Zugriffskontrollen Monitoring weitere organisatorische oder technische Vorgaben Ich nenne auch zusätzliche Vorschriften wie Code-Reviews, Vier-Augen-Prinzip oder neue regulatorische Anforderungen. Staat und Gesetzgeber Je nach Branche gelten weitere gesetzliche Vorgaben, zum Beispiel: Anforderungen an Barrierefreiheit Aufbewahrungspflichten revisionssichere Archivierung Diese Vorgaben können sehr konkrete Anforderungen an Software oder Infrastruktur auslösen. Sicherheitsverantwortliche Im Unternehmen kann es Rollen geben, die Sicherheitsanforderungen vorgeben. Beispiele sind: Zugriffsschutz Verschlüsselung Pentests vor dem Go-live Solche Punkte musst du bei Zeit, Budget und Planung berücksichtigen. Kulturkreis Wenn Software international eingesetzt wird, entstehen Anforderungen durch Sprache und Nutzungskontext, zum Beispiel: Übersetzungen unterschiedliche Schreibrichtungen Datumsformate Zahlenformate Management oder Geschäftsführung Diese Stakeholder interessieren sich vor allem für die wirtschaftliche und strategische Seite des Projekts, zum Beispiel: Amortisation Return on Investment strategische Passung Budget und Portfolio Skalierbarkeit Externe Dienstleistende Wenn externe Unternehmen beteiligt sind, können zusätzliche Anforderungen entstehen, etwa: technische oder organisatorische Schnittstellen Kommunikationswege Service-Level-Agreements Hardware beziehungsweise vorhandene Infrastruktur Auch technische Rahmenbedingungen können wie ein Stakeholder wirken. Beispiele sind: begrenzte CPU- oder RAM-Ressourcen Netzwerklatenzen begrenzter Speicherplatz Diese Limitierungen beeinflussen direkt, wie du dein Projekt umsetzen kannst. So kannst du in deinem Projekt vorgehen Ich empfehle dir ein schrittweises Vorgehen: Stakeholder sammeln Überlege zuerst, wer Interesse an deinem Projekt haben könnte. Stakeholder gruppieren Zum Beispiel in intern und extern oder nach anderen sinnvollen Kriterien. Repräsentierende Personen auswählen Du kannst nicht mit allen sprechen, also such dir passende Ansprechpersonen oder Rollen aus, etwa Key-User:innen. Anforderungen erheben Das kann oft einfach über Gespräche passieren. Bei Gesetzen oder Spezialthemen kannst du auch Fachpersonen wie Datenschutz- oder Sicherheitsbeauftragte einbeziehen. Anforderungen dokumentieren und priorisieren Schreib die Anforderungen auf, formuliere sie einheitlich und priorisiere sie. Daraus kann zum Beispiel ein Lastenheft entstehen. Widersprüche und Prioritäten prüfen Später kannst du analysieren, welche Anforderungen besonders wichtig sind und ob es Konflikte zwischen ihnen gibt. Beispiel aus einem kleinen Web-App-Projekt Ich nenne zum Schluss ein einfaches Beispiel: Benutzer:innen wollen eine einfache Oberfläche Admins wollen zum Beispiel Rechteverwaltung, Security-Vorgaben und Logging gesetzliche Vorgaben wie DSGVO müssen bei personenbezogenen Daten eingehalten werden Selbst bei einem kleinen Projekt kommen also schnell mehrere Stakeholder zusammen. Fazit Ich mache deutlich, dass du in deinem Projekt nicht nur an Kund:innen oder Benutzer:innen denken solltest. Es gibt viele weitere mögliche Stakeholder, deren Anforderungen dein Projekt beeinflussen. Wenn du diese Anforderungen frühzeitig sammelst, dokumentierst und priorisierst, reduzierst du das Risiko, dass dein Projekt an übersehenen Anforderungen scheitert. Genau daran entscheidet sich letztlich auch, wie erfolgreich und qualitativ dein Projekt ist. Links Permalink zu dieser Podcast-Episode RSS-Feed des Podcasts Transkription der gesamten Episode Automatisch erzeugte Transkription der Episode [0:20] Heute möchte ich mich mal mit einem Thema beschäftigen, was in, ja, eigentlich allen IT-Abschlussprojekten für die IHK-Prüfung relevant ist, und zwar die Stakeholder bei deinem Projekt. Welche es da so gibt, was die für Anforderungen haben könnten und welche du vielleicht vergessen hast bei deiner Stakeholder-Analyse, darüber wollen wir heute mal sprechen, sehe ich nämlich ganz oft. Normalerweise gehört zu jedem IT-Projekt, egal welche Fachrichtung, Systemmitigation, Anwendungsentwicklung, kaufmännisch, ganz egal, müssen wir eine Ist-Analyse machen, eine Anforderungsanalyse, sorry, bringe ich ein bisschen durcheinander gerade, die Anforderungsanalyse. Um die soll es heute gehen. Das heißt, welche Anforderungen soll dein Projekt überhaupt umsetzen? Und das ist ganz egal, ob ich eine Software entwickle oder irgendein System installiere, konfiguriere oder irgendein Angebot berechne. Ganz egal, was ich für ein Abschlussprojekt habe, es geht immer darum, wer will eigentlich was haben und für wen mache ich das und was wollen diese, meistens sind es Menschen oder Rollen oder Organisationen, Institutionen können es auch sein, wir gleich nochmal sehen, was wollen die von mir? Was haben die für konkrete Anforderungen an mein Projekt? Und diese Anforderungen muss ich aufnehmen, die muss ich dokumentieren, die muss ich im besten Fall priorisieren, die muss ich verfeinern und konkretisieren. Mit diesen Anforderungen steht und fällt der Erfolg meines Projekts. Denn du kennst vielleicht noch aus einer der unzähligen anderen Episoden, wo ich das Thema angesprochen habe, die Definition von Qualität. [1:39] Qualität ist der Grad der Übereinstimmung mit den Anforderungen. Und wenn ich keine Anforderungen habe oder die Anforderungen halb habe oder vergessen habe oder unklar habe, dann weiß ich gar nicht, ob ich qualitativ gearbeitet habe, ob ich fertig bin, ob das Projekt wirklich das tut, was es soll, weil ich eine Anforderung übersehen habe, vergessen habe etc....

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. 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. Kosten fair und anteilig umlegen 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 Kosten nicht selbst im Detail berechnen 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. Laufende Kosten nicht vergessen 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. Warum das für die Amortisation wichtig ist 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. Beispiele für mögliche Kosten Für Systemintegration 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 Für Anwendungsentwicklung 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. Meine Empfehlung für deine Projektdokumentation 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. Fazit 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. Links Permalink zu dieser Podcast-Episode RSS-Feed des Podcasts Betriebsabrechnungsbogen (BAB) für die IT-Berufe (AP1 und AP2) Transkription der gesamten Episode Automatisch erzeugte Transkription der Episode [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....

Um die Darstellung von Code in Projektdokumentation und Projektpräsentation geht es in der sechsten Episode der Shorts des IT-Berufe-Podcasts. Zusammenfassung der Episode In der aktuellen Episode meiner Podcast-Shorts dreht sich alles um die Kunst der Codepräsentation in Dokumentationen und Präsentationen – ein Thema, das gerade in der Prüfungsphase viele Prüflinge beschäftigt. Ich gebe praktische Tipps, wie ihr euren Code optimal aufbereitet, um in euren Dokumentationen und Präsentationen zu glänzen. Wir reden darüber, wie der Code in Dokumentationen anders aussehen sollte als in der IDE. Wichtig ist die Lesbarkeit: Setzt auf Struktur und Kontrast, und überlegt euch, ob der Dark Mode wirklich die beste Wahl ist. Ich erkläre, wie ihr den Fokus auf relevante Codeabschnitte legt und unwichtige Details ausblendet. Außerdem teile ich meine besten Hacks für PowerPoint, damit ihr euren Code Schritt für Schritt einblenden könnt – so zieht ihr die Aufmerksamkeit eurer Prüfenden auf eure Erklärungen! Und natürlich gibt es noch Hinweise zur Farbgestaltung, denn Schwarz auf Weiß ist meist der beste Kontrast. Hört rein, holt euch nützliche Tipps und bereitet euch bestens auf eure Prüfungen vor. Ich bin gespannt auf euer Feedback und wünsche euch viel Erfolg bei euren Projekten! ✨🎧 Inhalt Zusammenfassung Die Episode behandelt die Frage, wie Quelltext in Projektdokumentationen und Projektpräsentationen einer Abschlussprüfung für Fachinformatiker Anwendungsentwicklung sinnvoll dargestellt werden sollte. Ausgangspunkt ist die Beobachtung, dass in Prüfungsunterlagen häufig Code-Screenshots aus der IDE verwendet werden, oft zusätzlich im Dark Mode. Die zentrale Aussage lautet, dass Code in der Prüfung nicht so präsentiert werden sollte, wie er in der Entwicklungsumgebung für die tägliche Arbeit angenehm ist, sondern so, dass er im jeweiligen Medium optimal lesbar, verständlich und bewertbar ist. Ausgangslage und Prüfungsbezug Im Kontext der AP2 und der anschließenden Projektdokumentation sowie Projektpräsentation spielt Code eine zentrale Rolle, da er den Kern der Arbeitsleistung von Anwendungsentwicklerinnen und Anwendungsentwicklern darstellt. Dabei wird der Begriff „Code“ weit gefasst: Gemeint ist nicht nur klassischer Programmcode in Sprachen wie Java, C# oder PHP, sondern auch andere textbasierte Artefakte wie Jenkinsfiles, Dockerfiles oder Konfigurationsdateien, sofern sie Teil der technischen Lösung sind. Da diese Artefakte in Dokumentation und Präsentation bewertet werden, müssen sie so aufbereitet sein, dass Prüfende sie ohne unnötige Hürden erfassen können. Zentrale Qualitätsziele Für die Darstellung von Code in Prüfungsartefakten nennt die Episode drei Kernziele: Lesbarkeit Der Code muss visuell gut erfassbar sein. Dazu gehören ausreichende Schriftgröße, geeigneter Kontrast und eine Darstellung, die sich an das Ausgabemedium anpasst. Verständlichkeit Der gezeigte Ausschnitt muss in kurzer Zeit nachvollziehbar sein. Besonders in der Präsentation darf der Umfang nicht so groß sein, dass das Publikum während der Erklärung den Überblick verliert. Bewertbarkeit Gezeigt werden sollte genau das, was die eigene Leistung belegt. Unwichtige oder automatisch erzeugte Inhalte erschweren die Beurteilung und lenken vom eigentlichen Beitrag ab. Unterschied zwischen IDE und Prüfungsmedium Ein zentraler Punkt ist die Trennung zwischen Entwicklungsumgebung und Prüfungsmedium. In der IDE wird Code unter anderen Bedingungen gelesen und bearbeitet als in einer Dokumentation oder Präsentation: In der IDE wird oft an einem Bildschirm mit individueller Konfiguration gearbeitet. Die Dokumentation kann auf Papier, Tablet oder Laptop gelesen werden. Die Präsentation findet typischerweise in einem hellen Raum statt, oft mit Beamer oder Monitor. Daraus folgt, dass Formatierungsentscheidungen aus der IDE nicht automatisch für Doku oder Präsentation geeignet sind. Auch Seitenverhältnisse unterscheiden sich deutlich: Präsentationen meist im Format 16:9 Dokumentationen typischerweise im DIN-A4-Format Code sollte deshalb für jedes Medium separat aufbereitet werden, etwa durch angepasste Zeilenumbrüche und kompaktere Formatierung. Kritik an Screenshots Von Screenshots aus der IDE wird klar abgeraten. Dafür werden mehrere technische Gründe genannt: Screenshots sind nicht verlustfrei skalierbar; beim Zoomen werden sie unscharf oder pixelig. Text bleibt bei Vergrößerung nicht sauber lesbar. Screenshots enthalten oft störende IDE-Elemente wie Fehlermarkierungen, Warnungen, Refactoring-Hinweise oder Hinweise zur Code-Historie. Solche Einblendungen lenken von der eigentlichen Aussage ab und können im Prüfungskontext sogar unerwünschte Fragen auslösen. Empfohlen wird daher, Code als echten Text in Dokumentation oder Präsentation einzufügen. Das verbessert Skalierbarkeit, Lesbarkeit und Bearbeitbarkeit deutlich. Empfehlungen zur Formatierung Für die Formatierung des Codes werden mehrere konkrete Hinweise gegeben: Verwendung einer Monospace-Schriftart, damit Einrückungen und Ausrichtung korrekt bleiben Anpassung von Zeilenlängen und Umbrüchen an das Zielmedium Gegebenenfalls Änderung von Code-Konventionen für die Darstellung, etwa geschweifte Klammern ans Zeilenende statt in eine separate Zeile zu setzen, um Platz zu sparen Nur die relevanten Ausschnitte zeigen, nicht vollständige, kompilierbare Dateien Schlüsselwörter oder Modifier wie public, static, final weglassen, wenn sie für die Aussage nicht relevant sind Syntax-Highlighting verwenden, aber nur in einer Form, die die Lesbarkeit unterstützt Die Episode betont, dass Prüfungsunterlagen keine originalgetreue Abbildung der IDE sein müssen. Erlaubt und sinnvoll ist vielmehr eine auf das Publikum optimierte Darstellung. Bewertung des Dark Mode Ein Schwerpunkt der Episode ist die Kritik am Dark Mode in Dokumentation und Präsentation. Dabei wird ausdrücklich nicht der Dark Mode im Entwicklungsalltag kritisiert, sondern dessen Übertragung in Prüfungsunterlagen. Für Dokumentationen Gegen dunkle Hintergründe in der Dokumentation sprechen laut Episode mehrere Gründe: Schwarzer Text auf weißem Hintergrund bietet den besten Kontrast für das Lesen. Weißer oder farbiger Text auf schwarzem Hintergrund ist schlechter lesbar, insbesondere mit Syntax-Highlighting. Ausdrucke mit schwarzem Hintergrund verbrauchen unnötig viel Toner oder Tinte. Kommentare und Korrekturen auf ausgedruckten Seiten sind auf dunklem Hintergrund schlechter sichtbar. Für Präsentationen Auch in Präsentationen wird der Dark Mode als problematisch beschrieben: In hellen Räumen erscheint Schwarz oft eher grau, wodurch der Kontrast sinkt. Bei Displays oder Monitoren können dunkle Flächen stärker spiegeln. Reflektionen können die Sicht auf den Code zusätzlich erschweren. Die pragmatische Empfehlung lautet daher: Code für die Prüfung möglichst dunkel auf hellem Hintergrund darstellen. Verständlichkeit in der Präsentation Für die Präsentation wird empfohlen, Code nicht in großen Blöcken auf einer Folie zu zeigen. Stattdessen sollte er schrittweise eingeblendet werden, etwa zeilenweise. Begründung: Das Publikum liest sonst sofort den gesamten Code und hört der Erklärung nicht mehr zu. Die Aufmerksamkeit lässt sich besser steuern. Relevante Teile können gezielt erläutert werden. Diese Vorgehensweise ist mit Textobjekten in Präsentationstools deutlich einfacher als mit Screenshots. Auswahl des gezeigten Codes Besonders wichtig ist die Auswahl der Inhalte. Gezeigt werden sollte nur Code, der die eigene fachliche Leistung sichtbar macht. Nicht geeignet sind laut Episode insbesondere: generierte Getter und Setter Standard-Konstruktoren triviale Framework- oder Binding-Logik austauschbare Konfigurationsausschnitte ohne inhaltliche Tiefe HTML-Standardmarkup ohne projektspezifische Aussage Stattdessen sollte der Fokus auf dem fachlich interessanten Teil des Projekts liegen, zum Beispiel: projektspezifische Logik ein selbst entwickelter Algorithmus zentrale Teile der Domäne nicht triviale Datenverarbeitung Logik, die klar die eigene Denk- und Entwicklungsleistung zeigt Fazit der Episode Die Episode versteht Code-Darstellung als Teil der Prüfungsleistung. Ziel ist nicht, die gewohnte IDE-Darstellung zu reproduzieren, sondern die Inhalte so aufzubereiten, dass Prüfende sie schnell erfassen und fair bewerten können. Entscheidend sind dabei eine textbasierte statt bildbasierte Darstellung, hohe Lesbarkeit, reduzierte und zielgerichtete Ausschnitte sowie die Konzentration auf den individuellen fachlichen Beitrag. Die Kernaussage lässt sich so zusammenfassen: Für Dokumentation und Präsentation sollte Code mediengerecht vereinfacht, formatiert und ausgewählt werden, damit er die eigene Leistung klar und ohne Ablenkung zeigt. Höre dir jetzt die Podcast-Episode an! Links Permalink zu dieser Podcast-Episode RSS-Feed des Podcasts Kontrast und Farben Transkription der gesamten Episode Automatisch erzeugte Transkription der Episode [0:20] Während ich das hier aufnehme, sind schon wieder viele Prüflinge im Prüfungsstress, denn die AP2 steht an. Und direkt danach ist bei vielen IHK ja schon die Abgabe der Projektdokumentation. Und danach kommt dann die Projektpräsentation und dann ist endlich die Ausbildung beendet. Und ich werde auch dieses Jahr wieder einige Artefakte mir anschauen dürfen, Projektdokumentation lesen, Projektpräsentation anschauen und natürlich dann bewerten. Und da ich ja nun mal Anwendungsentwicklerinnen prüfe, werde ich da natürlich, solange wir noch Code schreiben müssen, als Anwendungsentwicklerinnen auch Code präsentiert bekommen. Entweder in der Doku oder in der Präsi oder im besten Fall in beiden. Denn das ist ja nun mal der Kern unseres Ausführungsberufs und das gehört natürlich dazu. [1:03] Und Code, damit meine ich nicht nur Programmiersprachencode, J

In der einhundertsechsundneunzigsten Episode des IT-Berufe-Podcasts bespreche ich mit Thomas Schmidt von BZEcom (Bildungszentrum für E-Commerce und IT) die neuen IT-Weiterbildungen, die 2024 eingeführt wurden. Wir analysieren die Hintergründe der jüngsten Veränderungen im Weiterbildungssystem für IT-Fachkräfte, insbesondere die Einführung des Berufsspezialisten in IT auf DQR-Stufe 5 und Bachlor Professional auf DQR-Stufe 6. Thomas erläutert die Fachrichtungen wie Datenanalyse, IT-Beratung und Informationssicherheit, die spannende Karrieremöglichkeiten bieten. Wir gehen auch auf das Prüfungsverfahren des neuen Abschlusses und dessen Vereinbarkeit mit dem Berufsleben ein. Zudem diskutieren wir die Finanzierungsmöglichkeiten, einschließlich des Aufstiegs-BAföG, die angehenden Fachkräften im IT-Bereich Unterstützung bieten. Diese Episode bietet wertvolle Informationen für jede und jeden mit Interesse an der Weiterentwicklung im IT-Bereich. Inhalt In dieser Episode des IT-Berufe-Podcasts widmen wir uns einem äußerst spannenden Thema: IT-Weiterbildungen und den neuen Abschlüssen, die 2024 in Kraft getreten sind. Ich führe ein ausführliches Interview mit Thomas Schmidt, der beim Bildungszentrum für E-Commerce und IT tätig ist. Thomas bringt uns auf den neuesten Stand, was die Veränderungen im Weiterbildungssystem für IT-Fachkräfte betrifft und erläutert die neuen Möglichkeiten, die sich aus den Überarbeitungen ergeben. Zunächst diskutieren wir die Hintergründe der Anpassungen, die notwendig wurden, weil die vorherigen Abschlüsse, insbesondere die sogenannten Operative Professionals am Markt nicht gut angenommen wurden. Die Reaktionen von Arbeitgebern waren klar: Sie benötigten Fachkräfte, die spezialisiert sind, aber nicht unbedingt Führungspositionen einnehmen. Daher wurde der Berufsspezialist in IT geschaffen, der auf Ebene 5 des deutschen Qualifikationsrahmens (DQR) angesiedelt ist und nun als attraktive Alternative für all diejenigen gilt, die ihre Ausbildung abgeschlossen haben und stoffliche Expertise nachweisen wollen. Thomas erläutert die zahlreichen Fachrichtungen innerhalb dieses neuen Abschlusses: Darunter fallen die Spezialisierungen in Datenanalyse, IT-Beratung, Informationssicherheit, Softwareentwicklung und Systemintegration. Dieser Fokus auf spezielle Fachkompetenz eröffnet nicht nur zahlreiche Karrieremöglichkeiten, sondern erlaubt es auch, dass sich Fachinformatiker oder Kaufleute für Digitalisierungsmanagement nach der Ausbildung gezielt weiter qualifizieren, ohne den traditionellen Weg eines Universitätsstudiums gehen zu müssen. Wir besprechen auch das Prüfungsverfahren für den Berufsabschluss sowie den Bachelor Professional in IT, der nun auf derselben DQR-Stufe wie ein Bachelorabschluss an Universitäten eingestuft ist. Thomas erklärt, dass die Prüfung sowohl schriftliche als auch praktische Bestandteile umfasst, einschließlich der Präsentation eines Projekts, was eine direkte Anwendung des erlernten Wissens im beruflichen Kontext darstellt. Dies ist besonders interessant für all jene, die bereits im Beruf stehen und sich fachlich verbessern möchten. Ein weiterer zentraler Punkt ist die Vereinbarkeit der Weiterbildung mit dem Berufsleben. Thomas gibt Einblicke in dieFlexibilität der Kurse, die sowohl in Abendveranstaltungen als auch in kompakten Blockkursen angeboten werden. Zudem werden die Teilnehmer bei der Vorbereitung auf die IHK-Prüfung durch praxisnahe Fallstudien unterstützt, um sicherzustellen, dass sie nicht nur für die Prüfung lernen, sondern auch wertvolles Wissen für ihren späteren Berufsalltag erhalten. Abschließend nimmt Thomas auch Bezug auf die Finanzierung dieser Weiterbildungen, einschließlich des Aufstiegs-BAföG, welches eine bedeutende Unterstützung für angehende Professionisten im IT-Bereich bietet. Er ermutigt alle, die an einer Weiterbildung interessiert sind, sich nicht nur um das persönliche Wachstum zu kümmern, sondern auch aktiv nach Anerkennung und Ermutigung von Arbeitgebern zu suchen. Diese Episode bietet umfassende Einsichten und Anregungen für alle, die an IT-Weiterbildungen interessiert sind, und zeigt die vielfältigen Möglichkeiten auf, die sich durch neue Abschlüsse ergeben können. Diese Fragen klären wir im gemeinsamen Gespräch: Wie kam es dazu, dass die bisherige IT-Weiterbildung modernisiert/überarbeitet wurde? Was sind die neuen IT-Berufsspezialisten bzw. Bachelor Professional in IT überhaupt? Für wen sind diese Abschlüsse geeignet und was bringen sie mir? Warum wurden die Abschlüsse neu entwickelt? Welche unterschiedlichen Berufsspezialisten gibt es? Wie ist der Zusammenhang von Berufsspezialisten und Bachelor Professional in IT? Was sind die Inhalte? Wie ist der Ablauf und die Dauer? Gibt es z.B. Blended Learning oder nur Präsenz/online? Wie sieht die Abschlussprüfung aus? Welche Qualifikationen sind Voraussetzung für die Weiterbildung? Warum sollte ich Bachelor Professional in IT werden und nicht einfach (dual) studieren gehen? Ist der Bachelor Professional in IT wirklich schon so anerkannt wie ein "richtiger" Bachelor, z.B. für Laufbahnen im öffentlichen Dienst? Wie bekannt/anerkannt sind die Abschlüsse bei Arbeitgebern? Welche Förderungen gibt es? Was ist das Aufstiegs-BAföG? Was fördert es genau? Wie läuft die Beantragung? Wie läuft die Rückzahlung? Links Permalink zu dieser Podcast-Episode RSS-Feed des Podcasts IHK-Weiterbildung zum Operative Professional mit Simon Stork - Anwendungsentwickler-Podcast #127 (der inzwischen überholte Abschluss) Thomas Schmidt bei LinkedIn Website zur IT-Weiterbildung von BZEcom IT-Karriere leicht(er) gemacht - Weiterbildungssystem neu aufgestellt – Rechtsverordnungen seit Ende 2024 in Kraft Neuordnung des IT-Weiterbildungssystems (BiBB) Das Aufstiegs-BAföG: die attraktivste Aufstiegsförderung aller Zeiten Transkription der gesamten Episode Automatisch erzeugte Transkription der Episode Einführung in die IT-Weiterbildung Stefan:[0:22] Herzlich willkommen zum IT-Berufe-Podcast, dem Podcast rund um die Ausbildung in den IT-Berufen. In dieser Episode gibt es ein spannendes Interview zum Thema IT-Weiterbildungen, und zwar dem neuen Berufsspezialisten bzw. Bachelor Professional in IT. Viel Spaß! Stefan:[0:40] Hallo und herzlich willkommen zur 196. Episode des IT-Berufe-Podcasts. Mein Name ist Stefan Macke und heute habe ich ein spannendes Interview mitgebracht für dich, Und zwar geht es um die neuen IT-Weiterbildungen. Vielleicht hast du das schon mitbekommen. Es gibt ja nicht nur die Ausbildung in Deutschland, sondern darauf aufbauen kann man sich ja auch fort- und weiterbilden. Und gerade Ende 2024 wurde das Weiterbildungssystem in der IT total überarbeitet. Früher, das hast du vielleicht schon mal mitbekommen, ich habe sogar eine Podcast-Episode dazu gemacht, hieß das Ding, was man danach machen konnte, Operative Professional. Und das wurde aber wohl am Markt nicht ganz so gut angenommen, sage ich mal vorsichtig. Und deswegen wurde das jetzt komplett überarbeitet und ist seitdem tatsächlich auch gleichbedeutend mit zum Beispiel einem Bachelorabschluss, den du an einer Hochschule machen kannst. Das ist laut dem DQR, dem Qualifikationsrahmen, auf der gleichen Stufe wie ein Universitätsabschluss. Und deswegen denke ich, dass das auf jeden Fall spannend ist, falls du deine Ausbildung schon beendet hast oder kurz davor schlägst und dir überlegst, Mensch, was soll ich denn danach machen? Soll ich studieren gehen oder was eigentlich? Was ist denn überhaupt die Alternative? Und genau über diese Alternative wollen wir heute mal sprechen. Und dazu habe ich mir einen spannenden Gesprächspartner mitgebracht, den Thomas. Der stellt sich auch gleich einmal vor, was er dazu überhaupt zu sagen hat zu Gespräch mit Thomas über IT-Weiterbildung Stefan:[1:58] diesem Thema und was so sein Hintergrund ist. Und ja, das war es mit vorgeplänkelt, würde ich sagen. Ich gehe mal direkt rein ins Interview. Viel Spaß dabei. Stefan:[2:08] Ja, erstmal hallo Thomas, schön, dass du heute da bist und mit mir über das spannende Thema der IT-Weiterbildung sprechen möchtest. Das habe ich bislang noch vernachlässigt, weil ich mich selber auch wirklich gar nicht gut damit auskenne. Da bin ich sehr froh, dass du euch hier bist und ein bisschen was darüber erzählen möchtest. Und bevor wir aber in das Thema eintauchen, würde ich mal so ein paar Standardfragen stellen. Und als allererstes natürlich frage ich dich, gut, wie du heißt, haben wir es gerade gehört, aber wer bist du, wo arbeitest du und warum bist du heute überhaupt hier? Erzähl doch mal ein bisschen was zu dir. Thomas:[2:32] Ja, hallo Stefan. Erstmal schön, dass ich da sein darf und was erzählen darf über die IT-Weiterbildung. Ja, Thomas Schmidt, also ich habe keinen Namen, sondern eine allgemeine Bezeichnung bekommen von meinen Eltern. Ich bin tatsächlich zuständig beim Bildungszentrum für E-Commerce und IT für Außenfortbildung. Ich habe tatsächlich IT nicht gelernt. Ich bin Politikwissenschaftler gelernt und habe mich aber immer mit Außenfortbildung beschäftigt und bin da tatsächlich jetzt in leitender Position zuständig, um das Unternehmen und Produktlandschaft weiterzuentwickeln. Stefan:[3:09] Okay, das heißt, du machst in der Außenweiterbildung nicht nur die IT, sondern auch noch, so als Beispiel, noch ein, zwei andere Berufe, irgendwas dabei? Thomas:[3:15] Genau, weil wir Bildungsanleitung für E-Commerce und IT sind, natürlich im E-Commerce-Bereich eben auch tätig, um dort für die Spezialisten im Online-Handel sozusagen noch was zu bieten. Stefan:[3:26] Okay, der Ausbildungsberuf gibt es inzwischen, glaube ich, Kaufmann, Frau für E-Commerce. Thomas:[3:30] Genau, Kaufmann, Kauffrau im E-Commerce ist die Seite, die tatsächlich dafür sorgen, dass der Shop funktioniert, dass die Produkte eingestellt werden, den ganzen Customer Journey