IT-Berufe-Podcast

Stefan Macke

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

  1. 3D AGO

    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
  2. APR 20

    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
  3. APR 13

    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
  4. APR 6

    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
  5. MAR 30

    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
  6. 12/15/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
  7. 11/10/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
  8. 07/28/2025

    Berechnung des eigenen Stundensatzes – IT-Berufe-Podcast-Shorts #4

    💼 Der Stundensatz für deine Projektdokumentation – Berechne ihn bitte nicht selbst! Hey, angehender IT-Profi! Heute dreht sich alles um ein Thema, das jeder Azubi kennt: den Stundensatz in der Projektdokumentation. Wie oft ich schon gefragt wurde, „Wie berechne ich meinen Stundensatz?“ – keine Sorge, ich hab’s auch mal durchgemacht! 🤷‍♂️ 📊 Warum ist der Stundensatz wichtig? Deine Projekte brauchen eine klare Kostenrechnung, egal ob sie klein oder groß sind. Wenn du über 80 Stunden arbeitest, kommt da so einiges zusammen! Doch solltest du deinen Stundensatz selbst berechnen? Klare Antwort: Lass es sein! 🚫 Das kann nur schiefgehen. 🏢 Arbeitgeber-Perspektive Die Berechnung muss aus Sicht deines Arbeitgebers geschehen. Versicherungen, Gemeinkosten – da wird viel mehr aufgerufen, als du vielleicht denkst. Du willst dir da keine falschen Zahlen umhängen – schau dir lieber die Zahl an, die die Personalabteilung für dich hat. 🔍 Warum nicht selbst rechnen? Die Wahrheit ist: Es gibt ganze Abteilungen, die sich mit solchen Kalkulationen beschäftigen. Wenn du versuchst, es selbst zu machen, könntest du auf die Nase fallen und unrealistische Stundensätze herausbekommen – 4 Euro? Unmöglich! 150 Euro? Nur in Ausnahmefällen! 🤦‍♂️ 📋 Die einfache Lösung Frag einfach bei deiner Personalabteilung nach – so sparst du dir den Stress. Halte fest, was im Stundensatz alles enthalten ist, und notiere das in deiner Dokumentation. Ein einfacher Satz reicht: „Der Stundensatz beträgt 40 Euro inklusive aller Kosten.“ 😊 🔑 Fazit: Mach’s dir leicht! Zusammengefasst: Berechne deinen Stundensatz nicht selbst. Frag nach und nutze die Zahl, die dir dein Unternehmen gibt. Vielleicht interessiert dich mehr darüber, wie die Berechnung erfolgt – ich habe dafür auch einen Podcast gemacht! Also, hör rein, aber lass die Finger von der Selbstkalkulation! Viel Erfolg bei deiner Projektdokumentation! 🖥️✨ Inhalt 📊 Warum benötigst du einen Stundensatz? Für deine Projektdokumentation ist es wichtig, eine Kostenrechnung zu machen. Das ist Pflichtprogramm, egal ob es sich um ein kleines oder großes Projekt handelt. Schließlich musst du auch deine Arbeitszeit berücksichtigen, und die kann bei 80 Stunden oder mehr schnell zusammenkommen! Das ist besonders relevant für Anwendungsentwickler und andere IT-Berufe. Doch nun zur entscheidenden Frage: Solltest du diesen Stundensatz selbst berechnen? Klare Antwort: Nein! 🙅‍♂️ Der Prozess ist so komplex und zeitaufwendig, da kannst du nur etwas falsch machen. Viele Azubis greifen zum einfachsten Mittel – sie nehmen einfach ihre Ausbildungsvergütung und rechnen damit. Falsch! Das ist nur die Sicht auf deinen Nettoeinkommen. Aber dein Arbeitgeber hat noch viel mehr auf dem Zettel, was es zu beachten gilt. 🏢 Die Perspektive des Arbeitgebers Die Berechnung des Stundensatzes muss also aus Sicht des Arbeitgebers erfolgen. Was deine Vergütung sind, ist lediglich die Spitze des Eisbergs. Arbeitgeber müssen Sozialversicherungen, zusätzliche Versicherungen und eine ganze Reihe von Gemeinkosten wie Hardware oder IT-Infrastruktur einpreisen. Diese Kosten werden dann auf deine Projektpreise umgelegt. Glaub mir, das dabei den Überblick zu behalten, ist kein Zuckerschlecken und sollte nicht in deine Hände gelegt werden! 🔍 Warum solltest du das nicht selbst tun? Die Wahrheit ist: Da gibt es ganze Abteilungen, die sich mit dieser komplexen Kalkulation befassen – Buchhaltung, Controlling, Rechnungswesen – du hast bestimmt schon von ihnen gehört. Die sind dafür zuständig und nicht du! Wenn du also versuchst, selbst einen Stundensatz zu berechnen, wirst du mit großer Wahrscheinlichkeit wichtige Aspekte übersehen und dich in einem Schlamassel wiederfinden. Das Schlimmste, was passieren kann? Du bekommst am Ende einen unrealistischen Stundensatz – von 4 Euro bis 150 Euro habe ich alles gesehen. Aber sei mal ehrlich, wie realistisch ist das? 4 Euro? Viel zu wenig, um damit leben zu können. Und die 150 Euro? Naja, in einem Großkonzern vielleicht, aber auch das ist eher die Ausnahme. 🤷‍♂️ 📋 Die richtige Herangehensweise Der Schlüssel ist, dass du einfach die Zahl von deiner Personalabteilung oder dem zuständigen Kollegen anfordest. So viel einfacher und weniger stressig. Notiere dir, was in diesem Stundensatz steckt – zum Beispiel: Ausbildungsvergütung, Lohnnebenkosten und Gemeinkosten. Das musst du in deiner Projektdokumentation anmerken, um zu zeigen, dass du verstehst, wie dieser Wert zustande kommt. Schreib einfach einen kurzen Satz, z.B.: „Der vorgegebene Stundensatz beträgt 40 Euro und beinhaltet alle notwendigen Kosten.“ 😊 Wichtig ist, dass du nicht versuchst, diesen Stundensatz selbst zu potenzieren oder zu analysieren – das führt nur zu Verwirrungen und Zeitverschwendung! 🔑 Fazit: Mach es dir einfach! Zusammengefasst heißt das: Berechne deinen Stundensatz nicht selbst. Frag einfach nach und nutze die Zahl, die dir dein Unternehmen bereitstellt. Und klar, es ist wichtig, dass du weißt, wie man diesen Stundensatz grundsätzlich berechnet. Aber du musst nicht ins Detail gehen und jede Kleinigkeit ausrechnen. Wenn du mehr darüber erfahren möchtest, wie die Berechnung eigentlich funktioniert, habe ich dazu auch einen Podcast aufgenommen – schau dir das auf jeden Fall an, aber verabschiede dich von der Idee, es selbst in deiner Doku zu machen. Du kannst nur verlieren – und das will ja keiner, oder? 💪 Mach’s gut und viel Erfolg bei deiner Projektdokumentation! 🖥️✨ Links Permalink zu dieser Podcast-Episode RSS-Feed des Podcasts Zusammensetzung des Stundensatzes – Häufige Fragen im Fachgespräch Transkription der gesamten Episode Automatisch erzeugte Transkription der Episode [0:21] Wie berechne ich den Stundensatz für meine Projektdokumentation korrekt? Ich weiß nicht, ob es eine Frage gibt, die mir häufiger gestellt wurde in den letzten Jahren. Und meine Antwort ist immer dieselbe. Lass es einfach sein. Berechne deinen Stundensatz bitte nicht selbst. Und heute will ich mal kurz darauf eingehen, warum das meine Standardantwort ist. Fang vorhin an. Stundensatz, wofür brauchen wir den? Du musst natürlich für deine Projektarbeit, also für das Projekt, das du umsetzt, in deiner Projektdokumentation eine Kostenrechnung machen. Das gehört, würde ich einfach mal pauschal sagen, bei jedem Projekt dazu. Egal, ob es sich am Ende amortisiert oder nicht. Das ist eine ganz andere Frage. Werde ich an anderer Stelle nochmal beantworten. Aber dass du die Kosten betrachten musst, das ist aus meiner Sicht Pflichtprogramm und ich glaube auch aus Sicht vieler anderen Prüfenden. Und da ist meistens der größte Brocken dein Anteil. Das heißt, deine, im Fall von Anführungsentwicklerinnen, 80 Stunden Arbeit, in den anderen IT-Berufen halt 40 Stunden. Da kommt ganz gut was zusammen, wenn man so eine Woche beziehungsweise zwei arbeitet. Und das sollte man in die Kosten auf jeden Fall einplanen. Ja, wenn man jetzt nicht gerade eine riesen Serveranschaffung als Fisi macht zum Beispiel, dann wird da nicht mehr viel Großartiges dazukommen, außer die eigene Arbeitsleistung. Deswegen sollte man das auf jeden Fall vernünftig mit einrechnen. Überhaupt keine Frage. Jetzt ist nur die Frage, die für dich interessant ist. Solltest du das selber machen? Und da ist meine ganz klare Antwort Nein. [1:41] Wenn du schon mal irgendwo in der Schule oder sonst irgendwo was zum Thema Stundensatz gehört hast, dann müsstest du wissen, wie kompliziert und umständlich und umfangreich es ist, einen richtigen Stundensatz für eine Person zu berechnen. Und was ich leider dann sehr, sehr häufig sehe in so einer Projektdokumentation, und das kann ich schon gar nicht mehr erzählen, wie oft ich das gesehen habe, dann nehmen dann halt einfach die Azubis ihre Azubi-Vergütung im dritten Ausbildungsjahr, teilen das durch ihre Arbeitstage, teilen das nochmal durch die Stunden pro Arbeitstag und schwupp, fertig ist der Stundenlohn. Stundenlohn, ich sage selber schon falsch, der Stundensatz natürlich. Übrigens Unterschied Lohn, Gehalt, Ausbildungsvergütung und Stundensatz. Solltest du dir unbedingt angucken für die Abschlussprüfung. [2:18] Hier geht es um den Stundensatz. Und das ist natürlich nicht alles, was da drin steckt. Das ist so die, wie soll ich sagen, die Sicht eines Arbeitnehmenden, der sagt, ja, das Geld, was bei mir auf dem Konto landet, das ist ja mein Stundensatz, ist ja klar. Ja, nee, sondern du musst den Stundensatz natürlich aus Sicht deines Arbeitgebers berechnen. Und der zahlt natürlich noch einen Haufen mehr Geld, als nur das, was bei dir auf dem Konto landet. Und müsste man jetzt nochmal den Unterschied zwischen Netto und Brutto wiederholen. Das wollte ich mir heute sparen. Aber es geht eben nicht nur darum, was du bekommst, sondern es gibt noch einen Haufen weiterer Kosten, die dein Arbeitgeber für dich zahlen muss. Nummer eins wären zum Beispiel die Sozialversicherungen, die on top kommen. Da gibt es vielleicht noch zusätzliche Versicherungen, die für dich abgeschlossen werden. Es gibt vielleicht, weiß ich nicht, vermögenswirksame Leistungen. Es gibt ganz sicher einen Riesenhaufen an Gemeinkosten, die in deinem Stundensatz mit drin sein müssen. So zum Beispiel deine Hardware, dein PC, dein Laptop, mit dem du jeden Tag arbeitest, der fällt nicht vom Himmel und den schenkt dir dein Arbeitgeber auch nicht, sondern der muss den auch irgendwie finanziert bekommen. Und wie funktioniert das? Indem er alle diese Dinge in deinen Stundensatz einpreist und der Kunde, der dich dann bucht und dein Projekt bezahlt, das darüber finanziert. Das heißt, alles, was nicht im Stundensatz drin ist, muss dein Arbeitgeber aus seiner eigenen Tasche zahlen. Und das will er nicht oder sie.

    11 min

Ratings & Reviews

About

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

You Might Also Like