IT-Berufe-Podcast

Stefan Macke

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

  1. 3 gg fa

    Realistische Dauer der Projektdokumentation – IT-Berufe-Podcast-Shorts #15

    Um die realistische Dauer deiner IHK-Projektdokumentation geht es in der fünfzehnten Episode der Shorts des IT-Berufe-Podcasts. Die wichtigste Aussage ist kurz: Plane für deine Projektdokumentation so viel Zeit ein, wie du bekommen kannst. Weil die Vorgaben der IHKen stark unterschiedlich sind und die Doku einen großen Einfluss auf deine Abschlussnote hat, lohnt es sich, deutlich mehr Zeit für Formulierung, Korrekturen, Feedback und saubere Aufbereitung einzuplanen. Die knappen "offiziellen" Zeitvorgaben für die umfangreiche Dokumentation sind unrealistisch, deshalb sollte die Doku in deiner Priorisierung weit oben stehen. Inhalt Wie viel Zeit du für die Projektdokumentation einplanen solltest Die kurze Antwort lautet: so viel Zeit, wie deine IHK dir erlaubt. Praktisch heißt das aber: Plane eher mehr Zeit ein, als offiziell irgendwo steht, weil die Projektdokumentation ein zentrales Prüfungsartefakt ist und einen großen Anteil an deiner Abschlussnote hat. Unterschiedliche Vorgaben der IHKen Ein zentrales Problem ist, dass die IHKen in Deutschland nicht überall gleich vorgehen. Manche IHKen erlauben, die Projektdokumentation innerhalb der offiziellen Projektzeit zu schreiben. Andere IHKen erlauben das nicht oder machen andere Vorgaben. Teilweise gibt es sogar feste Zeitanteile, zum Beispiel 15% der Projektzeit. Bei 80 Stunden Projektzeit in der Anwendungsentwicklung wären das dann 12 Stunden für die Dokumentation. Andere IHKen machen gar keine konkrete Zeitvorgabe, sodass du faktisch bis zur Abgabe daran arbeiten kannst. Dadurch entstehen sehr unterschiedliche Voraussetzungen. Wenn eine Person nur 12 Stunden einplanen darf und eine andere faktisch deutlich mehr Zeit nutzen kann, wirkt sich das fast zwangsläufig auf die Qualität der Dokumentation aus. Warum mehr Zeit sinnvoll ist Die Projektdokumentation wird bewertet. Entscheidend ist am Ende nicht, ob du exakt eine vorgegebene Stundenzahl eingehalten hast, sondern wie gut das Ergebnis ist. Deshalb sollte die Doku möglichst sauber und vollständig sein: Fehler korrigieren sauber formulieren Referenzen prüfen ein ordentliches Inhaltsverzeichnis erstellen Bilder und Artefakte sinnvoll in Anhang oder Dokument einbauen andere Personen Korrektur lesen lassen Die Empfehlung ist deshalb klar: Nutze jede realistisch verfügbare Zeit, um die Dokumentation rund zu machen. Offizielle Planung und praktische Realität Wenn deine IHK eine feste Zeitvorgabe macht, sollte diese natürlich in Projektplanung, Antrag und Dokumentation auftauchen. Gleichzeitig ist die Empfehlung, in der Realität trotzdem alle sinnvollen Möglichkeiten zu nutzen, um die Doku zu verbessern. Der Grund: Eine gute Note bekommst du nicht dafür, dass du nur wenig Zeit investiert hast, sondern dafür, dass die Dokumentation am Ende gut ist. Warum knappe Zeitvorgaben unrealistisch sind Gerade bei umfangreichen Dokumentationen mit zum Beispiel 40 oder 50 Seiten sind die sehr kleinen "offiziellen" Zeitvorgaben aus meiner Sicht unrealistisch. Denn zur Arbeit an der Doku gehört mehr als nur Schreiben: viele Seiten Text formulieren Inhalte überarbeiten Layout und Struktur sauber setzen Anhänge, Bilder und weitere Artefakte einbauen zusätzliche Materialien teilweise erst erstellen Eine umfangreiche, sauber gesetzte PDF-Dokumentation in nur 12 Stunden zu erstellen, ist nicht realistisch! Priorisierung: Doku vor Perfektion im Projekt Die klare Empfehlung lautet, deine Zeit nach dem Einfluss auf die Note zu priorisieren. Das bedeutet im Zweifel: lieber etwas weniger programmieren, konfigurieren oder installieren dafür mehr Zeit in die Projektdokumentation stecken Begründung: Die Doku hat einen sehr hohen Einfluss auf die Abschlussnote. Das eigentliche Projekt kannst du in Präsentation und Doku ohnehin nur ausschnittweise zeigen. Deshalb kann zusätzliche Zeit für Formulierung, Überarbeitung und Feinschliff bei der Doku mehr Wirkung auf die Bewertung haben als noch mehr Arbeit am eigentlichen Projekt. Natürlich kann man diese Prüfungslogik kritisch sehen – und das tue ich selbst auch. Denn eine umfangreiche Dokumentation zeigt nicht automatisch, wie gut jemand beruflich handlungsfähig ist. Solange die Prüfungsstruktur aber so ist wie sie ist, sollte man als Prüfling das Beste daraus machen. Zusätzlicher Zeitdruck in der Abschlussphase Diese Empfehlung ist in der Praxis nicht immer leicht umzusetzen. Gegen Ende der Ausbildung kommen oft mehrere Belastungen zusammen: laufende Arbeit im Ausbildungsunternehmen teilweise keine vollständige Freistellung in manchen Fällen Projektarbeit außerhalb der Arbeitszeit Vorbereitung auf die AP2 Vorbereitung auf Projektpräsentation und Fachgespräch Durchführung des eigentlichen Projekts Schreiben der Dokumentation Trotzdem bleibt die Doku aus Bewertungssicht ein Schwerpunkt, den du bei deiner Zeitplanung besonders beachten solltest. Abgrenzung: Projektdokumentation ist nicht dasselbe wie Benutzer- oder Entwicklerdoku Zum Schluss unterscheide bitte nochmal ganz klar zwischen den verschiedenen "Dokumentationen". Projektdokumentation Das ist das Prüfungsartefakt, um das es im gesamten Podcast geht. Fachliche Dokumentation im Projekt Dazu gehören zum Beispiel: Benutzerhandbuch Entwicklerdokumentation Klassendiagramm Administrationsdokumentation Netzplan Diese Unterlagen gehören ohnehin zum Projekt dazu und sind Pflichtbestandteile. Dafür gibt es bei vielen IHKen eigene Bewertungsanteile. Wenn solche Dokumentationen fehlen, kann sich das direkt negativ auf die Note auswirken. Realistische Planung für diese fachlichen Doku-Anteile Für diese projektbezogenen Dokumentationen sollte die Zeitplanung realistisch bleiben. Ein sehr umfangreiches Handbuch mit unrealistisch wenig angesetzter Zeit passt nicht. Kleinere Dokumentationsartefakte wie ein Netzplan oder ähnliche Unterlagen können dagegen mit wenigen Stunden realistisch geplant werden. Fazit Meine Kernaussage ist eindeutig: Investiere in die Projektdokumentation lieber mehr Zeit als zu wenig. Wegen der hohen Bedeutung für deine Note, der sehr unterschiedlichen IHK-Vorgaben und der unrealistischen offiziellen Zeitvorgaben lohnt es sich, genügend Zeit für Überarbeitung, Feedback und Feinschliff einzuplanen. Eine gute Dokumentation kann mehr Einfluss auf dein Ergebnis haben als zusätzliche Detailarbeit am eigentlichen Projekt. Links Permalink zu dieser Podcast-Episode RSS-Feed des Podcasts Transkription der gesamten Episode Automatisch erzeugte Transkription der Episode [0:21] So, heute habe ich mal ein kleines Thema mitgebracht und ich glaube, heute wird es wirklich mal ein Short. Und die Frage, die ich heute behandeln möchte, ist, wie viel Zeit sollte ich für meine Projektdokumentation einplanen? Also du weißt schon, das Prüfungsartefakt, das, was du dem Prüfungsausschuss vorlegst, wo ein sehr, sehr großer Teil deiner Abschlussnote von abhängt. Ja, genau dieses Ding, was je nach IHK zwischen 20 und 60 Seiten lang sein kann oder vielleicht noch kleiner oder noch länger. Ich weiß das nicht von allen 79 IHK, aber sagen wir mal im Durchschnitt vielleicht 30, 40, 50 Seiten. Dieses Ding, was du dann wahrscheinlich über eine Online-Plattform einreichst oder ausgedruckt und gebunden und ja, auch das habe ich schon gehört, bei der IHK einreichst, damit das bewertet werden kann. Wie viel Zeit brauchst du dafür? Und das Too Long Didn’t Read, was ich immer Games by Einschieger mache, ist, ganz kurz gesagt, so viel wie deine IHK dir erlaubt. So, was soll das wieder heißen? [1:18] Du weißt, 79 IHK gibt es in Deutschland. Jede macht wieder mal so ein bisschen ihr eigenes Ding, wenn sie möchte. Die meisten halten sich auch vielleicht eine einheitliche Vorgabe. Aber einige Sachen sind in den Berufsverordnungen der IT-Berufe halt nicht einheitlich geregelt. Zum Beispiel, ob die Projektdokumentationen überhaupt in deinen 80 oder 40 Stunden Projektzeit geschrieben werden dürfen. Einige IHK erlauben das, andere nicht. Und es kommt darauf an, wie man Gesetzestexte interpretiert und wer bei der IHK was entscheidet. Und ich weiß nicht, wovon es noch abhängt. Deswegen gibt es einfach ein Wir-Wahr an verschiedenen Lösungen und an verschiedenen Vorgaben und verschiedenen Wünschen, die IACAN so an diese Abschlussprojekte haben. Und da kann es dann durchaus sein, dass es da vielleicht auch harte Vorgaben gibt. Zum Beispiel innerhalb deiner Projektzeit ist das einzuplanen mit exakt 15 Prozent deiner Zeit. Und das wäre dann bei Anmerkungsentwicklung, wenn ich 80 Stunden habe, 12 Stunden der Projektzeit. Muss dann für die Projektdokumentationen. Eingesetzt werden. Andere IHK erlauben, dass man das einfach außerhalb der Projektzeit schreiben kann und geben gar keine Zeitvorgabe. Das heißt, da hast du quasi unendlich viel Zeit, also bis zur Abgabe der Doku natürlich, um deine Doku zu schreiben. Und da sieht man schon irgendwie, dass das ein bisschen unfair ist. Also wenn IHK einen Vorgaben machen, du darfst maximal zwölf Stunden dran sitzen und andere haben quasi unendlich viel Zeit. [2:36] Wie unterschiedlich sehen diese Dokus dann wohl aus, wenn ich wirklich nur zwölf Stunden in dieses Dokument stecke? Das kann ich ja gar nicht. so gut formulieren, gestalten, die Referenzen prüfen und ich weiß nicht was alles, wie jemand, der unendlich Zeit dafür hat. Also, da sieht man schon irgendwie, dass das alleine schon unfair ist. Und deswegen muss ich ehrlich gesagt sagen, aus meiner Sicht als Prüfer empfehle ich das sogar, es ist ganz egal, was dein IHK dir für Vorgaben macht. Nutze einfach so viel Zeit, wie du kriegen kannst, und mach diese Dokumentation perfekt, in Anführungszeichen. Lass da jemanden Korrektur lesen, im besten Fall jemanden, der sich auskennt, Ausbilder, Ausbilderin vielleicht. [3:15] Korrigiere alle Fehler, die dir auffallen, mach die Referenzen sauber, mach ein vernünftiges Inhaltsbezeichnis, pack alle Bilder in d

    12 min

  2. 29 giu

    Einhaltung der Projektbearbeitungszeit (40 bzw. 80 Stunden) – IT-Berufe-Podcast-Shorts #14

    Um die exakte Einhaltung der Projektbearbeitungszeit (40 bzw. 80 Stunden) beim Abschlussprojekt geht es in der vierzehnten Episode der Shorts des IT-Berufe-Podcasts. Für die betriebliche Projektarbeit solltest du die vorgegebene Zeit von 40 Stunden bzw. 80 Stunden in der Anwendungsentwicklung praktisch exakt einhalten. Mehr Zeit kann zum Nichtbestehen führen, weniger Zeit ist zwar rechtlich grundsätzlich möglich, verschlechtert aber unnötig deine Prüfungsleistung. Wenn deine Planung oder die IHK-Vorgaben unklar sind, solltest du das vor dem Projektantrag klären und dein Projekt so darstellen, dass du am Ende genau auf die erlaubte Stundenzahl kommst. Inhalt Kernaussage Für die betriebliche Projektarbeit gelten feste Zeitvorgaben: 40 Stunden in den meisten IT-Berufen und 80 Stunden in der Fachrichtung Anwendungsentwicklung. Diese Zeit solltest du im Projektantrag und in der Projektdurchführung möglichst exakt einhalten. Zeitvorgaben: mehr geht nicht Die rechtliche Grundlage – die Berufsverordnung – nennt für die betriebliche Projektarbeit eine Prüfungszeit von höchstens 80 Stunden. Daraus folgt: Weniger Zeit ist rechtlich grundsätzlich erlaubt. Mehr Zeit ist nicht erlaubt. Wenn du die erlaubte Zeit überschreitest, hältst du die Prüfungsvorgaben nicht ein und könntest dadurch durch die Prüfung fallen. Deshalb sollte in deiner Zeitplanung am Ende genau die erlaubte Stundenzahl stehen: 40 Stunden in den meisten IT-Berufen 80 Stunden in der Anwendungsentwicklung Warum die exakte Planung erwartet wird Projektplanung gehört zu den Ausbildungsinhalten in allen IT-Berufen. Dazu gehört auch, zeitliche Vorgaben einzuhalten. Auch wenn eine Planung auf die Stunde genau in der Realität oft unrealistisch ist, wird in der Prüfung erwartet, dass du dich an die formalen Vorgaben hältst. Dazu kommt: Prüfungsleistungen sollen vergleichbar sein. Ohne feste Obergrenze könnten einzelne Prüflinge deutlich mehr Zeit investieren als andere. Größere Projekte würden auch zu umfangreicheren Dokumentationen führen, die von Prüfenden gelesen werden müssten. Weniger Zeit ist zwar erlaubt, aber unklug Auch wenn das Gesetz "höchstens" sagt, ist weniger Zeit aus Sicht der Prüfungsleistung keine gute Idee. Wenn du freiwillig weniger Zeit nutzt, zeigst du weniger von deinen Fähigkeiten, nutzt deinen möglichen Bewertungsrahmen nicht aus, und stellst dich schlechter dar als jemand, der die volle Zeit sinnvoll ausschöpft. Die Aussage dazu ist klar: Weniger Zeit zu planen oder zu nutzen ist möglich, aber für deine Note eher nachteilig. Pufferzeit im Projektantrag Manche planen im Antrag bewusst Pufferzeit ein, weil Projekte nie perfekt planbar sind. Dabei gilt aber: Ob das erlaubt oder sogar gewünscht ist, hängt von der IHK ab. Es gibt IHKs, die einen Puffer akzeptieren oder fordern. Es gibt auch Fälle, in denen ein Antrag mit eingeplanter Pufferzeit abgelehnt würde. Die Empfehlung ist deshalb: Informiere dich vorher bei deiner IHK, welche Erwartungen gelten. Reiche den Antrag möglichst direkt passend ein, damit er nicht wegen solcher Punkte zurückkommt. Warum ein abgelehnter Antrag problematisch ist Wenn dein Projektantrag abgelehnt wird und du ihn überarbeiten musst, verlierst du Zeit durch Überarbeitung und erneute Prüfung, darfst du mit dem Projekt erst nach Genehmigung anfangen, und bekommst dadurch zusätzlichen Zeitdruck. Deshalb ist es sinnvoll, die formalen Anforderungen vorab zu klären. Abweichungen vom Projektantrag helfen bei Überziehung nicht Auch wenn es in Projektdokumentationen oft ein Kapitel zu Abweichungen vom Projektantrag gibt, kannst du damit keine längere Projektzeit rechtfertigen. Wenn dein Projekt mit 80 oder 40 Stunden genehmigt wurde, bleibt diese Vorgabe bestehen. Das heißt: Eine Überschreitung lässt sich nicht einfach dadurch retten, dass du sie in der Doku erwähnst. Der Prüfungsausschuss kann das als Verstoß gegen die Vorgaben werten. Umgang mit Abweichungen während des Projekts Wenn du in einer Projektphase mehr Zeit brauchst als geplant, solltest du in der Darstellung dafür sorgen, dass du diese Zeit in einer anderen Phase wieder einsparst, damit du am Ende insgesamt auf die erlaubte Stundenzahl kommst. Typisch ist dann ein Soll-Ist-Vergleich, in dem beschrieben wird, dass an einer Stelle mehr Zeit nötig war und an anderer Stelle entsprechend weniger. Auch wenn das in der Realität oft konstruiert wirkt, ist genau das Teil des Prüfungssystems. Fazit Die Antwort auf die Ausgangsfrage ist eindeutig: Mehr als die erlaubten 40 bzw. 80 Stunden solltest du nicht haben. Weniger wäre zwar grundsätzlich möglich, ist für deine Prüfungsleistung aber nicht sinnvoll. Plane dein Projekt so, dass du am Ende genau auf die vorgegebene Stundenzahl kommst. Wenn es Unklarheiten zu Pufferzeiten oder Formvorgaben gibt, kläre das vorher mit deiner IHK. Links Permalink zu dieser Podcast-Episode RSS-Feed des Podcasts FIAusbV: Verordnung über die Berufsausbildung zum Fachinformatiker und zur Fachinformatikerin Transkription der gesamten Episode Automatisch erzeugte Transkription der Episode [0:21] Heute habe ich mal ein Thema mitgebracht, woran ich immer denken muss, wenn ich mir wieder Projektanträge für die betriebliche Projektarbeit anschaue. Und zwar, muss ich eigentlich die vorgegebene Zeit für mein Projekt, nämlich 40 Stunden bei allen IT-Berufen und 80 Stunden bei der kleinen Ausnahme für AmnungsentwicklerInnen, muss ich diese Zeit eigentlich einhalten oder darf ich auch mehr oder weniger Zeit für mein Projekt haben? [0:46] Und kurz vorweg gesagt, nein, du darfst nicht mehr oder weniger haben. Du solltest ziemlich genau exakt auf diese Zahl kommen. Etwas aufgeweicht, ja, du darfst auch weniger Zeit aufwenden, aber das wäre dumm, aber da kommen wir gleich drauf. Aber wenn du überziehst, hast du ein Problem, damit kannst du durch die Prüfung fallen. Das heißt, das solltest du auf keinen Fall machen. Deswegen nehmen wir erst mal das Daumenregel mit. In deiner Zeitplanung sollten unten exakt 40 Stunden für alle IT-Berufe außer Anbietungsentwicklung bzw. 80 Stunden für die Anbietungsentwicklung stehen. Alles andere ist nicht so sinnvoll. Und da gucken wir jetzt mal drauf, warum das so ist. Also Nummer 1, Abweichungen nach unten sind grundsätzlich okay, aber dumm. Aber wir gucken mal warum. Und zwar schauen wir als allererstes mal auf die gesetzliche Grundlage, die Berufsverordnung. Und da weißt du vielleicht, wir haben sieben verschiedene IT-Berufe, die alle einzelne Berufsverordnungen teilweise haben, beziehungsweise der Fachnummer hat gerade eine mit vier Unterpunkten für die einzelnen Fachrichtungen und so weiter. Aber du kannst dir die alle online angucken. Besetztes Texte sind frei verfügbar. Und ich nehme jetzt einfach mal den Paragraf 12, der FIE aus BF, also der Berufsverordnung für die Fachinformatiker. Und den findest du ziemlich genau, exakt so formuliert auch in allen anderen IT-Berufsverordnungen. [2:01] Und da steht in Paragraf 12, Absatz 2, die Prüfungszeit beträgt für die betriebliche Projektarbeit und für die Dokumentation mit praxisbezogenen Unterlagenlagen, höchstens 80 Stunden. Die Prüfungszeit beträgt höchstens 80 Stunden. Kurz zusammengefasst. So, höchstens steht da. Da steht nicht, du musst exakt auf 80 Stunden kommen, was ja sowieso völlig unrealistisch ist. Kein Mensch kann ein Projekt so gut planen, dass er exakt genau 80 Stunden braucht. Sind wir uns alle einig, dass das sowieso Quatsch ist, glaube ich. Aber höchstens heißt, ich darf auch weniger. So steht es erstmal im Gesetz. Das heißt aber, höchstens heißt inklusive 80, aber darüber ist es vorbei. Das heißt, mehr ist nicht. Wenn du also länger gebraucht hast, dann hast du dich nicht an diese Vorgaben zur Prüfung gehalten und dann könntest du deswegen durch die Prüfung fallen. [2:50] So wie mein Beispiel in meinem Prüfungskurs war, dein Chef gibt dir 100 Euro mit, um Brötchen zu kaufen und dann kommst du wieder und sagst, ja Chef, ich habe 110 ausgegeben. Ja, das ist schön, aber das war nicht dein Budget. Und was ist dann das Endergebnis? Du musst die 10 Euro auf deine eigenen Tasche zahlen, außer du hast einen vernünftigen Chef, der gibt dir das Geld dann wieder, weil dafür hast du leckere Brötchen geholt. Aber so mal als Beispiel, wenn du ein Budget hast, was du einhalten musst, dann kannst du auch nicht sagen, ja, sorry, ich habe es doppelt so viel ausgegeben. So, das geht nicht, kann man nicht machen. Und hier ist es auch so, wenn es exakte Vorgabe ist, halte ich an 80 Stunden, mehr geht nicht und du machst mehr. Ja, dann kann man dich deswegen durch die Prüfung fallen lassen, weil du einfach nicht an diese Vorgaben dich gehalten hast. Das ist nicht gut. So, vor allem gehört Projektplanung in allen IT-Berufen zu den Ausbildungsinhalten. Da steht ein Ausbildungsrahmenplan drin, Projektplanung, das gehört auf jeden Fall dazu, das muss man lernen in jedem IT-Beruf. Und früher war das sogar explizit in der Verordnung genannt unter dem Punkt zeitliche Vorgaben einhalten. Dieser Begriff, zeitliche Vorgaben ein, stand explizit in der Berufsordnung in allen IT-Berufen, was man da vermitteln musste. Heute ist es ein bisschen aufgeweicht und so ein bisschen schwammig, Projektplanung und so weiter. Aber gehört dazu. Ich kann, wenn ich Software-Entwicklungsprojekte zum Beispiel plane, auch nicht sagen, ich brauche irgendwas zwischen 100 und 1000 Personentagen. [4:06] Die wollen das schon ein bisschen genauer wissen, die Leute, die das Geld dafür bezahlen. Und deswegen gehört das zum Ausführungsinhalt dazu. Und da kann ich auch nicht mal mein Abschlussprojekt sagen, irgendwas zwischen 10 und 100 Stunden. Das geht nicht. Man muss es schon vernünftig planen. So, wir sind uns alle einig, dass diese Planung sowieso utopisch, unrealistisch und meistens komplett überzogen wird in der Realität. [4:2

    14 min

  3. 22 giu

    Ist die Projektdokumentation Teil der Bearbeitungszeit des IHK-Abschlussprojekts (40h bzw. 80h)? – IT-Berufe-Podcast-Shorts #13

    Um das Einplanen der Projektdokumentation als Teil der Bearbeitungszeit des IHK-Abschlussprojekts (40h bzw. 80h) geht es in der dreizehnten Episode der Shorts des IT-Berufe-Podcasts. Bei der Frage, ob die Zeit für die Projektdokumentation in die 40 bzw. 80 Stunden der Projektarbeit gehört, gibt es keine einheitliche Regelung, sondern es hängt von deiner IHK ab. Viele IHKen und auch der DIHK verlangen, dass diese Zeit mit eingeplant wird, auch wenn das in der Praxis oft als unrealistisch gesehen wird. Ich würde dir deshalb empfehlen, die Vorgaben deiner konkreten IHK zu prüfen und im Zweifel die Doku-Zeit vorsichtshalber in die Planung aufzunehmen. Inhalt Ob die Zeit für die Projektdokumentation zur offiziellen Projektzeit zählt, ist je nach IHK unterschiedlich geregelt. Eine einheitliche bundesweite Regelung gibt es dazu nicht, obwohl sich viele Prüflinge genau diese Klarheit wünschen. Nach der Recherche im Podcast erwarten die meisten IHKen, dass die Dokumentation innerhalb der vorgegebenen 40 oder 80 Stunden entsteht. Gleichzeitig wird das als praxisfern bewertet, weil die Projektzeit ohnehin oft knapp ist und umfangreiche Dokumentationen zusätzlich kaum realistisch in wenigen Stunden erstellt werden können. Worum es bei der Frage geht Gemeint ist die Zeit für die finale Projektdokumentation für den Prüfungsausschuss, also das ausformulierte Dokument mit Inhalt, Struktur, Formatierung, Bildern und Anhängen. Die zentrale Frage ist, ob diese Zeit offiziell Teil der Projektbearbeitungszeit ist oder außerhalb davon läuft. Warum es dazu unterschiedliche Auffassungen gibt In den Berufsverordnungen steht, dass der/die Prüfling eine betriebliche Projektarbeit durchführen und mit praxisbezogenen Unterlagen dokumentieren muss. Außerdem wird dort genannt, dass die Prüfungszeit für Projektarbeit und Dokumentation höchstens 80 Stunden beträgt, bezogen auf die Fachinformatiker:innen Anwendungsentwicklung. FIAusbV §12 (2) Der Prüfling hat eine betriebliche Projektarbeit durchzuführen und mit praxisbezogenen Unterlagen zu dokumentieren. Die Prüfungszeit beträgt für die betriebliche Projektarbeit und für die Dokumentation mit praxisbezogenen Unterlagen höchstens 80 Stunden. Im ersten Teil hat der Prüfling nachzuweisen, dass er in der Lage ist, […] die Planung und Durchführung des Projektes anforderungsgerecht zu dokumentieren. Diese Formulierungen lassen sich unterschiedlich auslegen: Eine Auslegung ist, dass damit auch die finale Projektdokumentation für den Prüfungsausschuss gemeint ist. Die andere Auslegung ist, dass hier die fachliche Dokumentation gemeint ist, die ohnehin zum Projekt gehört, z.B.: Entwickler:innen-Dokumentation Benutzerhandbücher Installationsprotokolle Checklisten Netzpläne Nach dieser zweiten Sichtweise gehört die fachliche Dokumentation zum echten Projekt, nicht aber das spezielle Prüfungsartefakt für den Ausschuss. Einschätzung zur Praxis Es ist eigentlich offensichtlich, dass die vorgegebenen Projektzeiten oft schon für die eigentliche Umsetzung knapp sind. Wenn dann zusätzlich noch die vollständige Projektdokumentation in dieser Zeit erstellt werden soll, finde ich das sehr unrealistisch. Besonders kritisch sehe ich, dass manche IHKen für die Dokumentation nur etwa 10 bis 15 Prozent der Gesamtzeit vorsehen. Das wären bei 80 Stunden nur 8 bis 12 Stunden, bei 40 Stunden sogar nur 4 bis 6 Stunden. Rolle von IHK und DIHK Der DIHK hat eine Empfehlung beziehungsweise Vorgabe herausgegeben, nach der die Zeit für die Projektdokumentation mit eingeplant werden soll. Deshalb ist die Tendenz eher so, dass viele IHKen diese Zeit inzwischen in die Projektzeit einrechnen. Trotzdem gibt es unterschiedliche Regelungen je nach Region: Nicht in der Zeit enthalten: z.B. Regensburg, Bayreuth, Stuttgart In der Zeit enthalten: z.B. Oldenburg, Gera, Berlin, Bonn Beispiele Umsetzungsempfehlung DIHK: drin mit 20%, https://www.ihk.de/blueprint/servlet/resource/blob/6945168/0424ce44eab4c49eab8b0c078fe7d796/dihk-umsetzungshilfe-it-berufe-data.pdf Regensburg und Bayreuth: nicht drin, https://www.ihk.de/blueprint/servlet/resource/blob/6637094/a7a0c7a26a07c581efc8f6784bdf0c3c/it-berufe-hinweise-stand-15-07-25-data.pdf Stuttgart: nicht drin, "Auch das reine Dokumentieren des Projektverlaufs gehört zur Zeitplanung (nicht die Erstellung und Ausgestaltung der finalen Datei für den Prüfungsausschuss).", https://www.ihk.de/stuttgart/fuer-azubis/pruefungen/formulareneu6359/it-berufe-infos-ap2-6705038 Oldenburg, drin 15-20%, https://www.ihk.de/oldenburg/geschaeftsfelder/ausbildungweiterbildung/ausbildung/tipps-zur-ausbildung/it-berufe-leitfaden-abschlusspruefung-6733866 Gera, drin 20%, https://www.ihk.de/blueprint/servlet/resource/blob/3872458/df0b97a582369d0c4ae8bd448b1785aa/it-ihk-information-veroeffentlichung-internet-20170907-data.pdf Berlin und Bonn, drin 15%, https://www.ihk-bonn.de/fileadmin/dokumente/Downloads/Ausbildung/IT-Berufe/IT-Handreichung_IHK_Bonn_Rhein-Sieg_2.pdf In Oldenburg lehnen wir Projektanträge ab, wenn die Dokumentationszeit nicht in der Planung enthalten ist. Der Grund dafür ist die formale Vergleichbarkeit: Wer die Doku-Zeit nicht einplant, hätte auf dem Papier mehr Zeit für die eigentliche Entwicklung als andere Prüflinge. Was du für deine Planung mitnehmen kannst Prüfe zuerst die Vorgaben deiner eigenen IHK. Suche auf der Website nach Handreichungen, Merkblättern oder FAQ. Wenn du nichts findest, frage direkt nach, z.B. per E-Mail oder telefonisch. Wenn du keine klare Auskunft bekommst, ist es sinnvoll, die Zeit für die Projektdokumentation vorsichtshalber mit einzuplanen. Praktische Empfehlung Auch wenn die Regelung kritisch gesehen wird, ist die wichtigste Empfehlung, dich an die Vorgaben deiner IHK zu halten. So vermeidest du formale Probleme, z.B. eine Ablehnung deines Projektantrags. Wenn dein Antrag genehmigt wird, kannst du davon ausgehen, dass deine Zeitplanung formal passt. Fazit Die Frage, ob die Projektdokumentation zur Projektzeit zählt, lässt sich nicht allgemeingültig beantworten. Viele IHKen rechnen sie inzwischen mit ein, andere nicht. Weil die Regelung regional unterschiedlich ist und der DIHK eher die Einplanung unterstützt, ist der sicherste Weg: bei deiner IHK nachfragen und die dortige Vorgabe konsequent umsetzen. Links Permalink zu dieser Podcast-Episode RSS-Feed des Podcasts FIAusbV: Verordnung über die Berufsausbildung zum Fachinformatiker und zur Fachinformatikerin Umsetzungsempfehlungen für die Durchführung der Abschlussprüfung in den IT‐Berufen (DIHK) Transkription der gesamten Episode Automatisch erzeugte Transkription der Episode [0:21] Heute geht es um eine Frage, die sich viele Prüflinge stellen, wenn sie vor ihrer Projektdokumentation stehen. Und zwar soll ich die Zeit zum Erstellen der Projektdokumentation mit in die Bearbeitungszeit der Projektarbeit einplanen? Also ich erstelle die Projektdokumentation für den Prüfungsausschuss, das 20, 30, 40, 50 Seiten Dokument. Das muss ich ja auch irgendwie zusammenschreiben, formatieren etc. Die Zeit, die ich dafür brauche, gehört das mit in die 80 Stunden bzw. 40 Stunden meiner Projektzeit oder ist das extern und ich kann da so viel Zeit investieren, wie ich will? Und ja, es ist leider wieder so, dass die Antwort ist, es kommt drauf an. Und zwar auf die IHK. Wir haben ja 79 verschiedene in Deutschland. Und wie bei vielen anderen Themen, wo man sich fragen könnte, warum wird das nicht einfach zentral geregelt, ist es auch hier wieder so, dass jede IHK macht, was sie will, beziehungsweise machen kann, was sie will. [1:22] Kurz vorweg, die meisten IHK, die ich recherchiert habe, ich habe nicht alle 79 recherchiert, nein, aber die meisten, die ich gefunden habe, erwarten, dass die Doku jetzt in der Projektzeit geschrieben wird. Und kurz vorweg, bevor ich jetzt in die Details gehe, meine persönliche Meinung. Ich finde das total schwachsinnig. Ich finde es total bescheuert, dass wir in 40 oder 80 Stunden, was ja sowieso sehr, sehr wenig ist, um ein einigermaßen passendes Projekt umzusetzen und wo wir uns alle. [1:52] Ganz sicher sind, dass die meisten Prüflinge diese Zeit eh nicht einhalten, weil ihr Projekt deutlich länger dauert als diese 40 oder 80 Stunden, dass man dann auch noch erwartet, dass sie eine umfangreiche Projektdokumentation und bei manchen IHK’en sind das wirklich 50 Seiten mit Inhaltsverzeichnis, mit Anhang, mit Bildern, mit allem Pipapo, dann noch irgendwie damit reinquetschen. Und das muss natürlich dann an einen einigermaßen realistischen Anteil haben. Die Projektdoku darf natürlich nicht 90 Prozent der Zeit in Anspruch nehmen. Das heißt, dann gibt es so Vorgaben wie zwischen 10 und 15 Prozent. Das sind dann vielleicht, sagen wir mal, zwölf Stunden, also anderthalb Arbeitstage. Und dann kann man sich mal überlegen, wie realistisch das ist, dass ich 50 Seiten in anderthalb Arbeitstagen zusammenkriege. Ohne Fehler und wunderbar alle Referenzen aufgelöst und Bilder benannt und in der richtigen Reihenfolge und alles. Also das ist einfach utopisch unmöglich und absolut schwachsinnig, das in diese Zeit mit einzuplanen. Das ist meine persönliche Meinung zu diesem Thema. Und jetzt kommen wir zu der Meinung der IACAN. Und leider sehen viele IACAN das ein bisschen anders und sagen, nö, ist absolut sinnvoll und total realistisch, dass Prüflinge solche Dokumente auch noch innerhalb ihrer 40 oder 80 Stunden schreiben. Und deswegen ist das einzuplanen. [3:06] So, vorweg, bevor wir jetzt weiter in die Details gehen. Das eine ist, was du laut Vorgabe zu planen hast. Das andere ist die reale Welt. Und wir sind uns eh alle einig, dass die Projekte sowieso meistens nicht in der Zeit umsetzbar sind. Zumindest, wenn du einigermaßen eine vernünftige Note haben willst. Deswegen, ehrlich gesagt… [3:26] Drauf und schreibt das einfach außerhalb der Projektzeit. Und das tut mir in der Seele weh, da

    15 min

  4. 18 mag

    Mündliche Ergänzungsprüfung – Erklärung, Benotung, Inhalte und Vorbereitung – IT-Berufe-Podcast #197

    Um die mündliche Ergänzungsprüfung (MEP) inkl. Erklärung, Benotung, Inhalte und Vorbereitung geht es in der einhundertsiebenundneunzigsten Episode des IT-Berufe-Podcasts. Die mündliche Ergänzungsprüfung (MEP) ist die letzte Möglichkeit, wenn du in einer schriftlichen Prüfung aus Teil 2 der Abschlussprüfung durchgefallen bist und dadurch das Bestehen noch retten kannst. Sie ist nur für einen einzigen schriftlichen Prüfungsbereich in AP2 möglich, dauert etwa 15 Minuten und wird im Verhältnis 2:1 mit dem bisherigen Ergebnis verrechnet, weshalb sie eine schlechte Note nur begrenzt ausgleichen kann. Wichtig ist vor allem: Kläre Ablauf, Antrag und Termin direkt mit deiner IHK und bereite dich inhaltlich wie auf die betroffene schriftliche Prüfung vor, aber mit Fokus auf mündliches Erklären. Inhalt Mündliche Ergänzungsprüfung in den IT-Berufen Ich fasse hier die Regeln zur mündlichen Ergänzungsprüfung (MEP) nach der seit 2020 geltenden Berufsverordnung zusammen. Die MEP betrifft nur Prüflinge, die in einem schriftlichen Prüfungsbereich von Teil 2 der Abschlussprüfung durchgefallen sind und die Prüfung dadurch eventuell noch bestehen können. Wofür die MEP gedacht ist Die MEP ist dafür da, eine nicht bestandene schriftliche Prüfung in Teil 2 auszugleichen. Sie ist nicht dafür da, einfach eine Note zu verbessern. Wichtig dabei: AP1 kann nicht durch eine MEP ausgeglichen werden. Auch das Projekt in AP2 kann nicht durch eine MEP ausgeglichen werden. Die MEP ist nur für die drei schriftlichen Prüfungsbereiche von AP2 möglich: die zwei berufsspezifischen schriftlichen Prüfungen Wirtschafts- und Sozialkunde (WISO) Wann die Abschlussprüfung bestanden ist Die Abschlussprüfung ist bestanden, wenn folgende Bedingungen erfüllt sind (siehe Gewichtung der Prüfungsbereiche und Anforderungen für das Bestehen der Abschlussprüfung): Gesamtergebnis von Teil 1 und Teil 2 mindestens ausreichend Ergebnis von Teil 2 mindestens ausreichend In mindestens drei Prüfungsbereichen von Teil 2 mindestens ausreichend In keinem Prüfungsbereich von Teil 2 ungenügend Für AP2 heißt das praktisch: Du hast vier Prüfungsbereiche in AP2: Projekt schriftlicher Bereich 1 schriftlicher Bereich 2 WISO In mindestens drei von diesen vier Bereichen musst du mindestens eine 4 haben. Wenn das Projekt bestanden ist, darfst du in den drei schriftlichen Prüfungen höchstens einmal durchfallen. Das bedeutet: Eine 5 in einer schriftlichen Prüfung kann noch okay sein. Zwei 5en in den schriftlichen Prüfungen reichen nicht mehr. Eine 6 in einem Prüfungsbereich von Teil 2 ist ebenfalls nicht erlaubt. Wann du in eine MEP musst Eine MEP wird relevant, wenn du durch eine schriftliche Prüfung in AP2 das Bestehen verfehlst (siehe Mündliche Ergänzungsprüfung). Typische Fälle: zwei 5en in den schriftlichen Prüfungen → eine davon muss ausgeglichen werden eine 6 → diese muss mindestens so verbessert werden, dass sie nicht als 6 stehen bleibt Dabei gilt aber immer: Du musst mit der MEP überhaupt noch rechnerisch bestehen können. Wenn das nicht mehr möglich ist, gibt es keine MEP. Wer die MEP beantragen muss Rein rechtlich gilt: Der Prüfling beantragt die MEP selbst. In der Praxis kann es sein, dass die IHK das automatisch anstößt. Verlassen solltest du dich darauf aber nicht. Wenn deine Noten knapp oder kritisch sind, solltest du direkt bei deiner IHK nachfragen, wie das bei dir geregelt ist. In welchen Prüfungsbereichen die MEP möglich ist Die MEP ist nur in einem einzigen schriftlichen Prüfungsbereich möglich. Voraussetzungen: der Bereich muss zu den schriftlichen Prüfungen von AP2 gehören du musst dort schlechter als ausreichend sein, also unter 50 Punkten die MEP muss für das Bestehen der Abschlussprüfung überhaupt noch etwas ändern können Nicht möglich ist: MEP im Projekt MEP in mehreren Prüfungsbereichen MEP zur reinen Notenverbesserung Wie die MEP bewertet wird Die MEP dauert in der Regel 15 Minuten. Das Ergebnis wird zusammen mit der bisherigen schriftlichen Note im Verhältnis 2:1 verrechnet: schriftliches Ergebnis zählt zweifach Ergebnis der MEP zählt einfach Das neue Ergebnis im Prüfungsbereich wird also so berechnet: (schriftlich × 2 + MEP) / 3 Was diese Gewichtung praktisch bedeutet Die MEP hat nur begrenzte Hebelwirkung. Beispiele: Bei 40 Punkten in der schriftlichen Prüfung brauchst du 70 Punkte in der MEP, um auf 50 Punkte insgesamt zu kommen. Bei 30 Punkten brauchst du 90 Punkte in der MEP, um noch auf 50 Punkte zu kommen. Bei 25 Punkten brauchst du sogar 100 Punkte in der MEP, um auf 50 Punkte zu kommen. Ab 24 Punkten oder weniger kannst du rechnerisch in diesem Prüfungsbereich nicht mehr auf 50 Punkte kommen. Deshalb ist das Ziel bei einer sehr schlechten 6 oft nicht mehr, diesen Bereich noch auf eine 4 zu bringen, sondern die 6 wenigstens auf eine 5 zu heben, damit die Prüfung insgesamt vielleicht noch bestanden werden kann. Wie der Ablauf organisiert ist Dazu gibt es keine einheitliche Vorgabe in der Berufsverordnung. Deshalb ist der Ablauf von IHK zu IHK unterschiedlich. Möglich ist zum Beispiel: MEP direkt am Tag der mündlichen Prüfung separater zusätzlicher Termin rein mündliches Fachgespräch kurze Vorbereitung auf Aufgaben Aufgaben an Tafel oder Papier mit anschließendem Gespräch Entscheidend ist: Es muss eine mündliche Prüfung sein. Sie soll etwa 15 Minuten dauern. Alles Weitere kann je nach IHK und sogar je nach Prüfungsausschuss unterschiedlich sein. Deshalb ist der wichtigste praktische Hinweis: Frag direkt bei deiner IHK nach. Verlass dich nicht auf Berichte aus dem Internet oder auf Erfahrungen von anderen Prüflingen. Welche Inhalte in der MEP drankommen können Die Fragen müssen zu dem Prüfungsbereich passen, in dem du durchgefallen bist. Beispiele: bei WISO etwa Themen wie Arbeitsrecht, Tarifverhandlungen oder Jugendarbeitsschutz bei einer fachlichen Prüfung etwa SQL, Pseudocode, UML oder andere Inhalte des jeweiligen Prüfungsbereichs Früher konnte der Themenbereich enger eingegrenzt werden. Das ist heute nicht mehr so. Maßgeblich ist jetzt der gesamte Prüfungsbereich, in dem du durchgefallen bist. Das bedeutet: Du musst dich breit auf alle Themen dieses Bereichs vorbereiten. Du kannst nicht davon ausgehen, dass nur ein einzelnes Lieblingsthema gefragt wird. Wie du dich vorbereiten kannst Die inhaltliche Vorbereitung ist im Grunde dieselbe wie für die schriftliche Prüfung, in der du durchgefallen bist. Sinnvoll ist dabei: alte Prüfungen durcharbeiten typische Themen des Prüfungsbereichs sammeln Antworten mündlich formulieren und erklären üben mit einer anderen Person üben, zum Beispiel mit dein:e Ausbilder:in, Lehrkraft oder einer erfahrenen Person Wichtig ist der Unterschied zur schriftlichen Prüfung: In der MEP musst du die Inhalte mündlich verständlich erklären können. Du solltest also nicht nur Aufgaben lösen, sondern auch üben, wie du Begriffe, Abläufe und Zusammenhänge in Worten erklärst. Einschätzung zur MEP Die MEP ist keine einfache Notenrettung, weil die 2:1-Gewichtung rechnerisch viel verlangt. Trotzdem kann sie eine echte Chance sein, wenn das Bestehen noch möglich ist. Dabei gilt: Die Prüfenden wollen in der Regel nicht, dass du scheiterst. In einer mündlichen Prüfung gibt es oft mehr Möglichkeiten, durch Nachfragen und Umschreibungen noch zu zeigen, was du kannst. Trotzdem bleibt die MEP deine letzte Chance, deshalb solltest du dich gezielt vorbereiten. Wichtigstes Fazit Die MEP betrifft nur schriftliche Prüfungsbereiche von AP2. Sie ist nur möglich, wenn du in einem Bereich unter 50 Punkten liegst und damit das Bestehen noch retten kannst. Sie dauert etwa 15 Minuten. Die Bewertung erfolgt im Verhältnis 2:1 zugunsten der bisherigen schriftlichen Note. Der genaue Ablauf ist nicht einheitlich geregelt und hängt von deiner IHK ab. Wenn deine Noten kritisch sind, solltest du sofort selbst bei deiner IHK nachfragen, wie es weitergeht und ob du etwas beantragen musst. Für die Vorbereitung solltest du die Themen der betroffenen schriftlichen Prüfung wiederholen und vor allem das mündliche Erklären trainieren. Links Permalink zu dieser Podcast-Episode RSS-Feed des Podcasts Themen der schriftlichen IHK-Prüfungen der IT-Berufe Gewichtung der Prüfungsbereiche und Anforderungen für das Bestehen der Abschlussprüfung Mündliche Ergänzungsprüfung Prüfungsrechner aller Berufe von A-Z Transkription der gesamten Episode Automatisch erzeugte Transkription der Episode [0:21] Hallo und herzlich willkommen zur 197. Episode des IT-Brufe-Podcasts. Mein Name ist Stefan Macke und heute geht es um ein Thema, das ich vor langer, langer, langer Zeit schon mal im Podcast besprochen habe. Allerdings noch auf Basis der alten Berufsverordnung. Und die wurde ja 2020 komplett über den Haufen geworfen. Deswegen ist es dringend Zeit, das mal zu aktualisieren. Und zwar geht es heute um die mündliche Ergänzungsprüfung, die MEP. Was ist das? Warum braucht man das? Wann muss ich da rein? Wie wird die bewertet? Wie breite ich mich vor? Das soll heute das Thema sein. Die mündliche Ergänzungsprüfung betrifft vor allem die Prüflinge oder nicht nur vor allem, also nur die Prüflinge, die durch einen Teil, nee, nein, sorry, durch einen Bereich von Teil 2 der Prüfung durchgefallen sind. So, wir müssen aber genau auf die Begriffe hier achten. [1:10] Die Abschlussprüfung besteht ja aus zwei Teilen, der AP1 und der AP2. Und diese Teile haben jeweils Prüfungsbereiche. Die AP1 hat nur einen Bereich, nämlich die schriftliche Prüfung, aber die AP2 hat mehrere Bereiche. Und zwar einmal das Projekt, das Abschlussprojekt, was man machen muss, was natürlich auch den größten Anteil an der Note hat. Und dann gibt es aber noch drei weitere Prüfungsteile in AP2. Und zwar die zwei berufsspezifischen Prüfungen. Für Armungsentwickler ist das zum

    19 min

  5. 11 mag

    Umgang mit Fehlern in der Projektdokumentation in der Projektpräsentation – IT-Berufe-Podcast-Shorts #12

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

    13 min

  6. 4 mag

    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

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

  8. 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
Elenco completo (227)

Valutazioni e recensioni

5
su 5
3 valutazioni

Descrizione

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

Informazioni

  • Creatore
    Stefan Macke
  • Anni di attività
    2015 - 2026
  • Puntate
    227
  • Classificazione
    Contenuti adatti a tutti
  • Copyright
    © Stefan Macke
  • Sito web del podcast
    IT-Berufe-Podcast

Potrebbero piacerti anche…