IT-Berufe-Podcast

Stefan Macke

Der Podcast rund um die Ausbildung in den IT-Berufen (insb. Fachinformatiker für Anwendungsentwicklung) von Stefan Macke.

  1. VOR 2 TAGEN

    Sinnvolle Prüfungsvorbereitung mit alten IHK-Prüfungen – IT-Berufe-Podcast-Shorts #11

    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

    7 Min.

  2. 27. APR.

    Platzierung von Artefakten in der Projektdokumentation – IT-Berufe-Podcast-Shorts #10

    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

    18 Min.

  3. 20. APR.

    Sinnvolle Anzahl der Seiten der Projektdokumentation – IT-Berufe-Podcast-Shorts #9

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

    19 Min.

  4. 13. APR.

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

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

    24 Min.

  5. 6. APR.

    Eh-Da-Kosten und laufende Kosten bei der Projektarbeit – IT-Berufe-Podcast-Shorts #7

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

    17 Min.

  6. 30. MÄRZ

    Darstellung von Code in Projektdokumentation und Projektpräsentation – IT-Berufe-Podcast-Shorts #6

    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

    23 Min.

  7. 15.12.2025

    Das neue IT-Weiterbildungssystem – Berufsspezialist und Bachelor Professional in IT – IT-Berufe-Podcast #196

    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, de

    54 Min.

  8. 10.11.2025

    Prüfungsvorbereitungskurs zur AP1 – IT-Berufe-Podcast-Shorts #5

    Zusammenfassung der Episode: Prüfungsvorbereitung für die AP1 🎧 Hey Leute! Ich bin’s, Stefan Macke, euer Begleiter auf dem Weg zur AP1! 🙌 Heute dreht sich alles um die brandneue Prüfungsvorbereitung, die ich für euch ins Leben rufe. Wenn du deine Skills aufpolieren willst, bist du hier genau richtig! Was erwartet dich? Wir tauchen in wichtige Themen ein – vom ISO/OSI-Modell über UML-Diagramme bis hin zu Subnetting und IPv6. Keine Angst, ich mach das alles verständlich und hands-on! 😉 Besuche meine Seite dieperfekteihkpruefung.de für alle Infos und Termine. So läuft’s ab: Jeden Dienstagabend treffen wir uns in Microsoft Teams, um gemeinsam an prüfungsnahen Aufgaben zu arbeiten. So gehen wir direkt in die Materie, ohne langweilige Wiederholungen! 🚀 Die Sitzungen werden aufgezeichnet, sodass du jederzeit nachschauen kannst. Der Inhalt zählt! Falls du bereit für die AP1 bist und Lust auf interaktives Lernen hast, melde dich gerne zum Kurs an. Ich kann’s kaum erwarten, diese spannende Reise mit dir zu starten! Bis bald! 👋 Inhalt Prüfungsvorbereitung für die AP1 In diesem Kurs werde ich zusammen mit dir wichtige prüfungsnahe Themen behandeln. Das könnten zum Beispiel Klassiker wie das ISO/OSI-Modell oder die „beliebten“ UML-Diagramme wie Klassendiagramme und Aktivitätsdiagramme sein! Aber keine Sorge, ich werde sicherstellen, dass wir auch für den Subnetting-Kram und die neuesten Aspekte von IPv6 fit werden. 🚀 Es geht also direkt ans Eingemachte! Du fragst dich, wo du mehr Infos herbekommst? Einfach mal bei meiner Seite vorbeischauen: dieperfekteihkpruefung.de. Ich habe bereits einen Kurs zur AP2 für Anwendungsentwickler:innen erstellt, und nun wechsle ich auf die AP1, weil die nächsten Prüfungen schon bald anstehen! 👀 Ablauf der Vorbereitung Der Plan ist, dass ich einmal pro Woche einen Live-Termin in Microsoft Teams anbiete, wo wir gemeinsam an prüfungsnahen Aufgaben arbeiten. Ich werde dir meine eigenen Aufgaben zur Verfügung stellen und wir lösen diese dann zusammen. 🎯 Dabei möchte ich, dass wir die Zeit effektiv nutzen, um zu lernen und unser Wissen anzuwenden – und nicht irgendwelche alten Sachen wiederzukäuen. Und das Beste daran? Du kannst dich auf der Website über die genauen Termine informieren. Wir starten immer dienstags abends – optimal, um auch nach einem langen Arbeitstag noch den Kopf zusammenzustecken. 🔍 Wenn du an einem Termin nicht teilnehmen kannst, ist das auch nicht weiter schlimm. Alle Live-Sitzungen werden als Videos aufgezeichnet und sind danach jederzeit abrufbar! Der Inhalt ist König! Einige der Themen, die wir behandeln werden, sind unter anderem UML-Klassendiagramme, Aktivitätsdiagramme und das Entity-Relationship-Modell. Und natürlich steht auch Pseudocode auf der Liste!. Ich bin überzeugt, dass wir mit diesem interaktiven Ansatz eine echt spannende und effektive Vorbereitungszeit haben werden. Du bekommst die Möglichkeit, Fragen zu stellen und direkt mit mir und deinen Mitazubis zu interagieren. Das macht das Lernen doch gleich viel angenehmer, oder? Dein erster Schritt zur Vorbereitung Also, wenn du Lust hast, mit mir an deiner AP1 zu arbeiten, melde dich an und vielleicht sehen wir uns dann schon bald zu unseren Live-Sessions, die Ende November starten. Ich freue mich riesig darauf, mit dir gemeinsam für die Prüfung zu lernen! 👋 Links Permalink zu dieser Podcast-Episode RSS-Feed des Podcasts Transkription der gesamten Episode Automatisch erzeugte Transkription der Episode [0:20] Falls du dich gerade auf deine AP1 in einem IT-Beruf vorbereitest, dann bleib vielleicht mal kurz dran, denn ich starte bald einen Prüfungsvorbereitungskurs für die AP1. Und falls du mit meiner Hilfe ein paar prüfungsnahe Aufgaben bearbeiten willst, ein bisschen die üblichen Themen so durchkasten, man willst in der AP1 so drankommen, sei es das OSI-ISO-Modell, beziehungsweise ISO-OSI, oder UML-Klassendiagramme-Sequenzdiagramme, Nee, Sequenzierung bekomme ich gerade in der AP1. Nee, aber hier Aktivitätsdiagramme zum Beispiel. Oder natürlich Netzwerktechnik und so weiter. [0:55] Dann, ja, guck doch mal vorbei auf meiner Seite. Vielleicht ist das ja ganz interessant für dich. Die Seite ist dieperfekteihkprüfung.de. Die Prüfung bitte mit UE schreiben. Ich weiß, es ist ein langes Wort. Dieperfekteihkprüfung.de. Alles zusammen ohne Bindelstrich. Kleingeschrieben natürlich und mit UE. Und da kannst du mal reingucken. Ich habe bislang einen Prüfungsvorwaltungskurs nur für die AP2 für Anwendungsentwicklerinnen gemacht. [1:19] Da habe ich jetzt quasi ein halbes Jahr die Inhalte schon zur Verfügung gestellt. Falls dich das eher interessiert, dann kannst du da mal reingucken. Das ist jetzt quasi ein reiner Online-Kurs. Die ganzen Videos sind online, kannst du dir angucken. Und jetzt schwenke ich um auf die AP1, denn während ich das hier aufnehme, steht sehr bald die AP2 für Anwendungsentwicklerinnen an, im Jahr 2025. Deswegen ist es wenig sinnvoll, danach direkt weiterzumachen mit der Prozessvorbereitung. [1:46] Ich würde es dann so machen, dass ich jetzt erst mal zur AP1 switche, denn die nächste, die jetzt ansteht, ist im Februar 2026. Und wenn die dann durch ist, switche ich wiederum zur AP2, weil dann kommt als nächstes im, ich glaube Ende April, Und 2026 die nächste AP2. Und dann switche ich wieder zur AP1. Also ich wechsle immer so zwischen den beiden Prüfungsteilen hin und her, je nachdem, welche als nächstes ansteht. Und jetzt wäre es aktuell so, dass ich switchen würde zur AP1 und fange jetzt mal mit den üblichen Netzwerkthemen an und Subnetting und IPv6 und IPv6, würde ich wohl eher sagen, und was sonst so ansteht. Und was ich so für Themen geplant habe, bislang kannst du auf der Website nachschauen. Die Idee ist, dass ich einmal wöchentlich einen Live-Termin mache in Microsoft Teams. und da sprechen wir dann prüfungsnahe Aufgaben durch, die ich mir natürlich selbst ausdenke und versuchen, die dann zu lösen. Die Vorbereitung auf die Termine gibt es dann quasi mit bereits bestehenden Podcast-Episoden oder YouTube-Episoden oder was auch immer. Denn ich möchte dann die Prüfungsvorbereitung wirklich dafür nutzen, um auch Aufgaben zu bearbeiten und nicht zum x-ten Mal das Wissen vorzukauen. Das kann man auch wie zum Beispiel in einem Podcast-Format oder YouTube-Video besser. Ja, wenn du Interesse hast, mit mir zusammen für die Prüfung zu lernen, AP1, Termine sind immer dienstags abends. [2:56] Beziehungsweise, ich glaube, ein, zwei Ausweichtermine, weil ich da was anderes zu tun habe auf dem Mittwoch. Immer so gegen 18 Uhr und du kannst dir alle anstehenden Termine auch online einfach anschauen. Wie gesagt, dieperfekte.ihrk-prüfung.de kannst du mal reinschauen und wenn du dich für die AP2 schon vorbereitest, auch das, der Kurs ist auch online verfügbar, kannst du die Videos angucken. Ich habe auch schon zum Start des Kurses einige Videos aus meinem AP2 Vorbereitungskurs übernommen. Das heißt, auch wenn du jetzt da dich schon anmeldest, kannst du schon einige Stunden Videomaterial zu Themen, die auch in der AP1 dran kommen, dir anschauen. Zum Beispiel das UML-Klassendiagramm, das Aktivitätsdiagramm, ER-Modelle, das Entity-Relationship-Model, also Pseudocode vor allem, auch immer geringenommen. Das heißt, einige Inhalte kann ich quasi eins zu eins wiederverwenden und die gibt es jetzt schon online. Die restlichen Inhalte werden dann quasi nach jedem Live-Termin als Video dort zur Verfügung gestellt. Du musst also nicht immer zu den Terminen dabei sein, aber das lohnt sich natürlich, weil du dann Fragen stellen kannst. Das geht natürlich im Nachhinein dann schwierig. [3:56] Ja, falls dich das Thema interessiert, guck gerne mal rein. Ich wiederhole es nochmal, die perfekte IHK-Prüfung.de und vielleicht sieht man sich dann ja ab Ende November 25. Dann geht es los mit dem ersten Termin in der Prüfungsvorbereitung zur AP1 für alle IT-Berufe. Würde mich freuen. Wir sehen uns vielleicht. Mach’s gut. Ciao.

    5 Min.
Alle anzeigen (222)

5
von 5
173 Bewertungen

Info

Der Podcast rund um die Ausbildung in den IT-Berufen (insb. Fachinformatiker für Anwendungsentwicklung) von Stefan Macke.

Informationen

  • Erstellt von
    Stefan Macke
  • Jahre aktiv
    2015 - 2026
  • Folgen
    222
  • Bewertung
    Unbedenklich
  • Copyright
    © Stefan Macke
  • Sendungswebsite
    IT-Berufe-Podcast

Das gefällt dir vielleicht auch