stefan.macke

Hallo [Eight],

falls du auf der Suche nach einer Vorlage für die Abschlussdoku bist, schau dir gerne mal meine LaTeX-Vorlage an. Die ist zwar für Anwendungsentwickler geschrieben, enthält aber natürlich auch die Bereiche, die für alle IT-Berufe einheitlich sein dürften (Projekt- und Kostenplanung, Amortisationsrechnung, Inhaltsverzeichnis usw.). Vielleicht hilft sie dir ja, um ein besseres Bild von den erwarteten Inhalten zu bekommen.

Viele Grüße!

Stefan

Die Klassiker sind sicherlich das "Handbuch für Fachinformatiker" und das "IT-Handbuch".

Ersteres deckt so ziemlich alle Themenbereiche der Prüfung ab und erklärt sie auch sehr gut. Das Buch ist gut geschrieben, gibt einen Überblick über alle Themen und eignet sich hervorragend als "Bettlektüre" Man muss sich bei über 1000 Seiten aber ein wenig Zeit nehmen.

Das zweite Buch ist quasi das Standardwerk. Es durfte bis vor Kurzem sogar noch als Nachschlagewerk mit in die Prüfung genommen werden. Ist allerdings mehr stichpunktartig aufgebaut und nicht so gut zu lesen. Man sollte die Themen schon aus einer anderen Quelle gelernt haben, dann ist es eine gute Gedankenstütze, um schnell wieder ins Thema zu kommen oder mal eben die Übertragungsgeschwindigkeit von ISDN nachzuschlagen

Ansonsten bietet der U-Form Verlag eine Vielzahl an Vorbereitungsunterlagen für die Abschlussprüfung an. Unter anderem die bisherigen Abschlussprüfungen. Das ist meiner Meinung nach die beste Möglichkeit, sich vorzubereiten, da du dabei auch gleich die Fragestellung der IHK kennenlernst.

Viele Grüße und viel Erfolg bei der Prüfungsvorbereitung!

Für alle, die zwar gerne die Vorlage nutzen würden, aber von LaTeX abgeschreckt werden, habe ich nun eine mehrteilige Einführung in LaTeX in Form von kurzen Screencasts erstellt, die man sich hier kostenlos anschauen kann: LaTeX-Einführung | Fachinformatiker Anwendungsentwicklung. Die Quelltexte und Beispiel-PDFs sind bei Github verfügbar: StefanMacke/latex-einfuehrung

Weiterhin bin ich für jegliches Feedback zur Vorlage dankbar. Die neue Adresse zum Download ist: Vorlage für die Projektdokumentation | Fachinformatiker Anwendungsentwicklung.

Ich weiß, der Thread ist alt, aber ich habe aktuell sowohl für die Projektdokumentation, als auch für die Projektpräsentation ein Beispiel mit Einsatz von TDD und agiler Entwicklung. In der Doku und auch in der Präsi (sogar mit Quelltextbeispiel) wird auf beide Themen eingegangen. Und ganz nebenbei sind beide Artefakte mit 100% bewertet worden

Hier sind die Beispiele: Projektdokumentation, Projektpräsentation

Es hat etwas länger gedauert (5 Jahre ), aber nun habe ich endlich ein "echtes" Beispiel für eine Präsentation, wie ich sie oben geschildert habe. Und jetzt kommt das Wichtigste: Sie wurde mit 100% bewertet. Sicherlich nicht allein aufgrund des Designs, sondern hauptsächlich aufgrund des Inhalts. Aber ich denke, man sieht doch deutlich den Unterschied zu den "klassischen" Präsentationen.

Wer Interesse an diesem Beispiel hat: http://fachinformatiker-anwendungsentwicklung.net/projektpraesentation-von-gerda-feldhaus-mit-100-bewertet/

Hier also nochmal mein Appell an alle Prüflinge: Traut euch etwas "Neues" und weicht vom alten Pfad der langweiligen Präsentationen ab! Auch die Prüfer werden es zu schätzen wissen.

Desweiteren wär ich auch jedem dankbar, der mir einen Tipp geben kann, was ich beruflich machen könnte, ohne sich jetzt mit einem Hungerlohn rumärgern zu müssen.

Dazu fällt mir dieser Beitrag von DRadio Wissen ein, den ich letztens gehört habe: Wie man mit Keksen den Traumjob findet.

Zusammenfassung: In Berlin gibt es eine "Traumjobdetektivin", die einem den passenden Traumjob sucht. Kostet aber ein bisschen was...

Viele Grüße!

Stefan

Hi Heftig,

ich habe eine umfangreiche Vorlage für die FIAE-Doku erstellt mit vielen Hinweisen zu Inhalten und Beispielen: Umfangreiche Vorlage für die Projektdokumentation inkl. Beispielen zum Download

Viele Grüße!

Stefan

Ich nutze für meine Dokumente KOMA-Script Documentation Project | Aktive Anwender verbessern KOMA-Script. bzw LaTeX-Wörterbuch: fancyhdr

Das schaue ich mir mal an!

Nein, z.B. liegen die ERDs und Klassendiagramme unter Bilder

Das stimmt, aber mir gefällt es besser, wenn alle Bilder in einem Ordner liegen. Ist wohl Geschmackssache und kann man ja anpassen, wenn man mag.

Groß-Klein-Schreibung

Ok, das baue ich dann mal ein.

Welchen Editor verwendet ihr denn zum erstellen eurer Dokumente?

Ich benutze TeXlipse in Zusammenarbeit mit SumatraPDF. Habe vorher viel mit LaTeX Editor gearbeitet, aber TeXlipse ist schon sehr cool. Du kannst auch BibTeX etc. damit bearbeiten und es hat halt die bekannten Funktionen und Shortcuts von Eclipse.

Viele Grüße!

Stefan

Hallo flashpixx.

Meines Wissens wird ja z.B. bei einem \section automatisch ein Seitenumbruch erzeugt

Bei der von mir verwendeten Dokumentenklasse wird kein Seitenumbruch bei einer Section erzeugt. Die manuellen Umbrüche habe ich hauptsächlich deswegen gesetzt, weil einige Grafiken sonst ungünstig platziert worden wären.

Bei komplexeren Arbeiten (> 50 Seiten) empfehle ich letztendlich immer, dass man kapitelweise die Daten organisiert, so dass man im Hauptdokument dann schnell die Kapitel vertauschen kann. Jedes Kapitel wird dann analog strukturiert, so dass man im besten Fall pro Subkapitel eine Datei hat mit den entsprechenden Kapiteldaten (Bilder, etc).

Deine vorgeschlagene Inhaltsstruktur habe ich ja genauso umgesetzt: In der Inhalt.tex kann man die einzelnen Kapitel beliebig hin- und herschieben. Und jedes Kapitel hat eine eigene Datei unter \Inhalt.

Bei diesem Fall kannst Du aber nicht darauf eingehen, wenn das z.B. an einem Satzanfang steht

Das Problem mit dem "z.B." am Satzanfang stimmt natürlich, wobei ich persönlich keinen neuen Satz damit beginnen würde ;-)

Du kannst direkt \today nehmen

Das \today ist lediglich ein Platzhalter. Das konkrete Datum dürfte bei einer echten Arbeit ja eh fix sein (also z.B. das Abgabedatum) und gar nicht dynamisch erzeugt werden. Ich ändere das mal in der nächsten Version auf ein fixes Datum ab, dann wird deutlicher, dass man es ändern muss.

Wofür dann eine fbox? Subfig sollte dies innerhalb der figure-Umgebung auch bieten

Das Beispiel mit der fbox stammt nicht von mir. Ich werde mir deinen Vorschlag mal anschauen.

Ebenso würde ich dazu raten, dass man Ordner- und Dateinamen klein schreibt, damit ggf keine Probleme entstehen, wenn die Daten mal auf ein unixoxides System portiert werden sollten.

Das verstehe ich nicht ganz: Ich verwende in den Dokumenten doch die korrekte (Groß-)Schreibweise der inkludierten Dateinamen. Warum sollte das unter Linux nicht funktionieren?

Viele Grüße!

Stefan

Hallo flashpixx.

Erstmal danke für das Feedback.

Du baust keinen Glossar, sondern ein Acronym Verzeichnis.

Korrekt, aber das war auch so gewollt. Da habe ich mich bei der Benennung etwas vertan. Dein Glossar schaue ich mir mal an und baue es ggfs. ein.

Ich würde von natbib bezügl. der Flexibilität abraten und statt dessen CTAN web interface: package biblatex verwenden.

Ok, das werde ich mir mal anschauen und ggfs. einbauen.

\clearpages sollte man mit Bedacht verwenden, im Normalfall macht LaTeX das viel besser.

Richtig. Aber die von mir gesetzten \clearpages sind durchaus mit Bedacht gesetzt :-) Ich habe sie erst eingefügt, nachdem mir im fertigen Dokument nicht gefallen hat, wie LaTeX einige Seiten umgebrochen hat.

Anführungszeichen werden mit \glqq bzw \grqq (für die deutschen) codiert.

Bei Verwendung des Pakets german kann man durchaus auch die von mir verwendete Schreibweise nutzen: siehe Wikibooks.

Ansonsten finde ich diese Struktur extrem unübersichtlich, gerade die Präambel sollte man zusammenhalten und nicht so auseinander reißen, falls man ggf Paketoptionen anpassen muss.

Ok, das mag für dich gelten. Ich persönlich finde die Struktur so sehr viel übersichtlicher, da Einsteiger z.B. nur die Seitenstil.tex editieren müssen und nicht von hunderten Packagedefinitionen erschlagen werden.

Diese ganze eigenen Definitionen sind im Grunde zu viel, weil man direkt die Befehle eingeben kann.

Das sehe ich nicht so. Die von mir definierten Befehle sorgen zum einen dafür, dass man bestimmte häufige LaTeX-Befehle nicht mehrfach verwenden und damit auch mehrfach anpassen muss, wenn man die Darstellung ändern möchte (z.B. \itemd). Zum anderen dienen sie der semantischen Textauszeichnung, wodurch eine Entkopplung von Bedeutung und Darstellung des Textes erreicht wird, was wiederum zu einer einfacheren Änderung der Darstellung führt (z.B. alle \Eingaben kursiv anstatt fett). Ganz zu schweigen von typographischen Ungeheuern wie "z.\,B.", dem ich \zB durchaus vorziehe ;-)

Bei Graphiken sollte man eine figure-Umgebung (ggf floatfig) verwenden und nicht fbox.

Das mache ich ja auch. fbox wird lediglich für eine einzige Ausnahme verwendet (zweiseitiges PDF im Anhang).

Im PDF ist das Inhaltsverzeichnis nicht klickbar, d.h. man kann nicht direkt die Kapitel anspringen.

Das ist falsch. Es ist allerdings nur die Seitenzahl verlinkt und nicht der Kapiteltext, da ich das optisch nicht so ansprechend finde. Siehe linktocpage in Packages.tex.

Für Use-Case & Klassendiagramme gibt es Welcome to MetaUML, UML for LaTeX/MetaPost und für Diagramme aller Art TikZ and PGF | TeXample.net

Danke, das kannte ich noch nicht. Werde mir das mal anschauen.

Viele Grüße!

Stefan

Moin Allrounder.

Das passt ja gut: Gerade vor ein paar Tagen habe ich hier meine LaTeX-Vorlage zur Projektdokumentation veröffentlicht. Du musst "nur noch" die Inhalte einfügen und dich um den Dokumentenaufbau nicht kümmern: Umfangreiche Vorlage für die Projektdokumentation inkl. Beispielen zum Download.

Nichtsdestotrotz empfehle ich dir natürlich, dich in LaTeX einzuarbeiten. Sonst wird die Fehlersuche sehr mühsam ;-)

Viele Grüße!

Stefan

Guten Abend zusammen.

Ich habe in mühevoller Kleinarbeit eine LaTeX-Vorlage für die Projektdokumentation zusammengestellt: LaTeX-Vorlage für IHK-Projektdokumentationen zum Fachinformatiker Anwendungsentwicklung.

Die Vorlage dürfte nicht nur für LaTeX-Nutzer oder Anwendungsentwickler interessant sein, sondern auch für Azubis in anderen IT-Berufen, da sie neben dem Layout auch eine Vorstrukturierung möglicher Inhalte und viele praktische Beispiele umfasst. Konkret werden die folgenden Punkte abgedeckt:

• Hinweise zu den geforderten Inhalten mit Quellenangaben
  
• Deckblatt
  
• Inhaltsverzeichnis
  
• Abbildungs- und Tabellenverzeichnis
  
• Abkürzungsverzeichnis/Glossar
  
• vorstrukturierte Kapitel für den eigentlichen Inhalt mit Stichpunkten und Beispielen (Zeitplanung, Stundensatzrechnung, Use Case-/Klassendiagramm, ERM, Mockups u.a.)
  
• Literaturverzeichnis
  
• Eidesstattliche Erklärung
  
• Anhang
  

Ich würde mich über Feedback - gerne auch ein kritisches - zur Vorlage freuen.

Viele Grüße!

Stefan

Also ich rechne so mit 1 Monat full Time Arbeit

Da gibt es wenig zu sagen: Schreib das auf keinen Fall in die Doku. Du hast 70h zur Verfügung. Punkt. Du solltest in 3 Jahren Ausbildung gelernt haben, ein Projekt wenigstens ungefähr passend zu planen. Die doppelte Zeit ist definitiv nicht tragbar. In der Realität sieht das alles anders aus, das ist mir bewusst. Aber das Abschlussprojekt muss vergleichbar für alle Prüflinge sein und daher musst du den gesteckten Zeitrahmen unbedingt einhalten. Ich habe noch nicht eine Doku gelesen, in der nicht 70h erreicht wurden.

Und wenn du selbst schon schreibst, dass du noch ein paar Zusatzfunktionen einbaust, hat das doch gar nichts mehr mit deinem Projektantrag zu tun. Lass das besser sein. Das Projekt kann (und sollte) selbstverständlich nach Beendigung der Projektzeit fortgeführt werden, aber das ist nicht mehr Teil der Abschlussprüfung!

Viele Grüße!

Stefan

auf meinen antrag hat die ihk raufgeschriebend as ich den Quellcode per CD mit meinem Projektantrag vorlegen muss

Das ist doch super. Dann weißt du jetzt bescheid, was du tun musst :-) Bei meiner eigenen Prüfung (vor einigen Jahren) musste ich das auch so machen. Aber inzwischen setzen viele IHKen (u.a. auch meine) ein Online-System ein, bei dem maximal eine PDF-Datei hochgeladen werden kann. Dann wären die erwähnten 1-3 Seiten Quelltext im Anhang sinnvoll.

Viele Grüße!

Stefan

@Akku: Ok, ich gebe mich geschlagen :-)

Klar, in der mündlichen Prüfung kann man Prüflinge schnell "enttarnen". Das hatte ich auch schonmal bei jemandem, der sein eigenes ERM nicht skizzieren konnte. Aber die 15 Minuten, die dafür zur Verfügung stehen, sind leider sehr schnell rum.

Ich würde mir einfach wünschen, dass die Prüflinge ihre Fähigkeiten nicht nur theoretisch (wie in der schriftlichen Prüfung) demonstrieren, sondern auch praktisch. Ich hatte auch schon einige Prüflinge, die beides super hinbekommen haben und in der Doku sinnvolle und interessante Quelltextauszüge angefügt haben. Aber es gibt halt leider auch die oben erwähnten Ausnahmen.

Vielleicht schließen wir das Thema ab mit der Erkenntnis, dass sich (einige) Prüfer über interessante Quelltexte in der Doku freuen und sie positiv für den Prüfling bewerten (sofern sie die benötigte Qualität aufweisen). Und Prüflinge, die keinen Code anhängen, sollten sich darüber im Klaren sein, dass die Prüfer durchaus Mittel und Wege kennen, um herauszufinden, ob jemand entwickeln kann oder nicht.

Viele Grüße!

Stefan

Das verstehe ich nicht. Warum findet ihr es komisch oder gar unnormal, wenn in einer Abschlussprüfung zum Anwendungsentwickler Code erwartet wird? Kein Bäcker besteht seine Abschlussprüfung, wenn er keine Brötchen backen kann. Jeder Elektriker muss Stromkabel ziehen können...

Wo außer in der Doku haben die Prüfer die Möglichkeit, das tatsächliche Handwerk des Prüflings bewerten zu können? UML-Diagramme und ER-Modelle können keinesfalls ein lauffähiges, qualitativ hochwertiges Programm ersetzen. So sehe ich das einfach. Und das hat nichts mit "Generalverdacht" zu tun. Im Gegenteil: Jeder Prüfling sollte doch gerne zeigen wollen, was er gelernt und geleistet hat.

Viele Grüße!

Stefan

Hallo!

Hier ist ein Beispiel für ein "Merkblatt zur Abschlussprüfung" der IHK Oldenburg: http://www.ihk-oldenburg.de/download/ka_merkblattprojektarbeit.pdf

Zitat:

maximal 15 DIN-A-4 Seiten plus 25 Seiten Anhang (inkl. Deckblatt, Inhaltsverzeichnis)

Vielleicht hat deine IHK ja auch so ein Dokument...

Viele Grüße!

Stefan

Somit dürfte der Prüfling nicht zur Prüfung zugelassen werden oder aber der Antrag in Zweifel gezogenwerden.

Naja, zum Zeitpunkt der Antragsstellung kenne ich den Prüfling noch gar nicht. Seine Fähigkeiten kann ich also nicht einschätzen, auch nicht nach ein paar Stichworten im Antrag. Jeder Antragssteller kann sicherlich irgendwie Code schreiben, aber ob dieser auch den Anforderungen entspricht, die ich an Code eines ausgebildeten Fachinformatikers stelle, kann ich nur beurteilen, wenn ich diesen Code sehe.

Dafür hast du doch das Fachgespräch.

Viele Prüflinge können in der mündlichen Prüfung die allgemeinen Fragen zum Bereich OO usw. gut beantworten, aber am Code sieht man trotzdem ernste Probleme (wie erwähnt: SQL-Injections, Fehler bei Grenzwerten, fehlende Eingabevalidierung etc.). Und da kann man mir noch so viele UML-Diagramme um die Ohnren hauen, der Code lügt nicht. Ich kann hier nur für mich sprechen, und ich misstraue einer Doku ohne angehängten Code einfach.

Viele Grüße!

Stefan

Ich bin selbst Prüfer und sehe das etwas anders. Klar ist es bei der aktuellen Einschränkung der Doku auf eine Seitenzahl von max. 40 nicht sinnvoll, den gesamten Quelltext des Projekts anzuhängen. Aber ich gehe nicht einfach davon aus, dass der Prüfling schon irgendwie programmieren kann. Und leider ist das auch bei einigen Prüflingen nicht der Fall (wer daran die Schuld trägt, sei mal dahingestellt).

Ich halte es für absolut sinnvoll und sogar erforderlich, interessante Quellcodeauszüge anzuhängen (vielleicht 1-3 Seiten). Damit meine ich zentrale Algorithmen, an denen man die Eigenleistung des Prüflings erkennen kann. Ich hatte auch schon viele Dokus mit seitenweise HTML/CSS und absolut trivialem Programmcode (z.B. Eingabevalidierung etc.). Das ist definitiv nicht sinnvoll und wurde offensichtlich dazu verwendet, die Seiten voll zu bekommen.

Du solltest aber darauf achten, dass der Code deine Fähigkeiten als Entwickler verdeutlicht und nicht voll mit Lücken für SQL-Injection, Rechtschreibfehlern und nicht nachvollziehbarer Logik ist (auch das habe ich bereits mehrfach gesehen).

Viele Grüße!

Stefan

Hi Ludas,

ich denke, die Foren-Suche sollte dir weiterhelfen!

Aber ich habe aktuell auch gerade eine kleine Liste aufgestellt:

fiae [stefans Wiki]

Viele Grüße

Stefan

Das stimmt natürlich. TDD kann man in vielen Vorgehensmodellen verwenden, wobei es sein Haupteinsatzgebiet aber wohl im Rahmen agiler Methoden (insb. XP) haben dürfte. Mein geplantes Vorgehen würde TDD ja genau in das altbekannte Vorgehen integrieren. Mich würde nur interessieren, ob es jemanden gibt, der sein Abschlussprojekt wirklich einmal "rein" agil entwickelt hat und vor allem, was die Prüfer dazu gesagt haben...

Hallo zusammen.

Hat von euch schon einmal jemand ein Abschlussprojekt durchgeführt/betreut/bewertet, bei dem anstatt der "üblichen" Vorgehensweise (Analyse, Entwurf, Implementierung, Test, Übergabe) agile Methoden des Projektmanagements (wie z.B. Scrum, Extreme Programming oder Feature Driven Development) angewendet wurden? Wenn ja, wie wurde das Projekt im Vergleich zu anderen (klassischen) Projekten bewertet (wenn man das objektiv sagen kann)?

Insbesondere interessiert mich hierbei der Einsatz von Unit-Tests oder gar von Test Driven Development. Der Einsatz von automatischen Tests sollte heutzutage (in Zeiten von Clean Code Developer etc.) für alle Softwareentwickler zum guten Ton gehören, aber hat tatsächlich schon einmal jemand die testgetriebene Entwicklung in seinem Abschlussprojekt zum FIAE eingesetzt? Alle Beispiele und Diskussionen, die ich gesehen habe, hielten sich immer an die (seit Jahren bewährte!?) klassische Vorgehensweise.

Mich würden eure Meinungen und Erfahrungen im Bereich der agilen Softwareentwicklung und insbesondere von TDD sehr interessieren. Wie ich im Thread zum Thema "Presentation Zen" gelernt habe, sind Prüfungsausschüsse nicht immer leicht von "neuen" (naja, TDD ist nun schon 10 Jahre alt) Vorgehensweisen zu überzeugen und im Moment tendiere ich dazu, meine Azubis eine Kompromisslösung aus klassischem Vorgehen und TDD anzuwenden: Ganz konkret würden sie eine Analyse und einen Entwurf bis auf Komponentenebene machen, die Klassen dann aber testgetrieben entwickeln. Dadurch hätten sie für die Dokumentation z.B. einen gröberen Entwurf und keine separate Testphase.

Was haltet ihr davon?

Wenn ich mir das alles so durchlese, frage ich mich, ob du Tipps haben möchtest oder uns von der Zen-Methode überzeugen möchtest...

Nachdem dir die meisten Prüfer jetzt davon abgeraten haben, würde ich es an deiner Stelle nicht auf Biegen und Brechen trotzdem probieren.

Naja, in diesem Thread wollte ich ursprünglich mal Tipps zur FI-Präsentation haben und grundsätzlich möchte ich andere von den "Zen-Präsentationen" überzeugen Nachdem ich nun allerdings recht deutliche Stellungnahmen von anderen Forenmitgliedern (insb. Prüfern) gegen "Zen" erhalten habe, werde ich meinen Azubis einfach empfehlen, sich selbst ein Bild zu machen. Ich bin nach wie vor der Meinung, dass man auch einen technischen Prüfungsausschuss mit der Zen-Methode überzeugen kann und sie am Ende nicht als "Spielerei" abgetan wird. Aber ich sehe ein, dass die Abschlusspräsentation für die Prüflinge ein wenig zu wichtig ist, um zu experimentieren. Nichtsdestotrotz glaube ich, dass es auch Azubis gibt, die mit der Zen-Methode gut umgehen können und damit authentischer rüberkommen als mit dem alten Foliendesign.

Das Datum macht noch Sinn!

...

Ich würde das Firmentemplate verwenden.

Argh! Naja, zum Thema Fußzeile und CI habe ich mich ja schon ausgelassen

Ich hab' ihr den Vorschlag gemacht, dass sie ein Blatt Papier nimmt und aufschreibt, was sie eigentlich erzählen will. Und um die Visualisierung kümmern wir uns dann gemeinsam. Späer, wenn der Inhalt festliegt.

Genau der richtige Ansatz! "Get analog" aus Presentation Zen: Die Präsentation wird "offline" entwickelt und erst im Anschluss in PowerPoint (oder wo auch immer) visualisiert.

Und da genau sehe ich die Gefahr: die Azubis neigen ohnehin schon dazu, ihre Vorträge (auch inhaltlich!) an das Layout anzupassen. Durch das CI werden sie wenigstens auf ein halbwegs vernünftiges Grundlayout festgenagelt, welches für Spielereien kaum Platz läßt. Und so können sie sich auf die Inhalte konzentrieren.

...aber genau das finde ich als Schlussfolgerung aus dem obigen Ansatz gerade nicht! Durch die CI ist man doch insbesondere im Aufbau der Folien so stark eingeschränkt, dass man gar nicht mehr die (offline) erarbeitete optimale Darstellungsform für die Inhalte umsetzen kann, da man nur noch 50% der Seite Platz hat zwischen Kopf- und Fußzeile (das ist nicht übertrieben, es gibt tatsächliche solche Templates) und diese festen Inhalte der Seite einem jegliche Möglichkeit zur freien Gestaltung nehmen.

Nix gegen Zen und neue Ideen ... ich hab' im Herbst einen 15-min-Vortrag für 800 Leute auf 'ner Betriebsversammlung mit 1:87-Figuren aus'm Modeleisenbahnladen visualisiert ... das geht. Aber 'n Azubi ist dafür in der Regel zu jung und zu unerfahren.

Siehe oben: Ich kenne durchaus Azubis, denen ich das zutrauen würde...

Du hättest mit diesen auf Schow ausgelegten Vortrag bei einer fachlichen Präsentation keine gute Karten.

...

Oder ganz kurz: Thema und Zielgruppe verfehlt.

Das ZEN-Gedönz erinnert mich auch mehr an Marketing Roadshow und nicht an einen technisch versierten Fachvortrag.

Ich verstehe nicht, warum das als "Show" oder "Marketing" abgestempelt wird. Dass die Folien so aussehen, heißt doch nicht, dass der Vortragende keine Ahnung hat! Das wird meiner Meinung nach viel eher durch die zusammenkopierten Punktlisten-Folien verdeutlicht, weil sich der Vortragende gar nicht im Klaren ist, was er eigentlich als Kerninhalt rüberbringen will, und zu faul, sich Gedanken zu machen, wie man den (hier so oft als "trockenen", nicht "spannend" rüberzubringenden) technischen Inhalt ansprechend verpacken kann. Ich bin der Meinung, dass Vortragende, die sich sehr gut mit ihrem Inhalt auskennen, mit der Zen-Methode viel eher einen bleibenden Eindruck hinterlassen, als mit den stumpfen, langweiligen Fakten-Folien. Und Zen heißt eben nicht, die Fakten wegzulassen und nur bunte Bildchen aufzulegen, sondern sich intensiv (viel stärker als bei den Punkt-Folien) mit dem Inhalt und seiner Zielgruppe zu beschäftigen und die bestmögliche Darstellungsform zu finden.

Wenn ich mir jetzt noch den dazugehörigen Vortrag vorstelle, dann könnte s richtig eng werden!

Die Folien allein sagen selbstverständlich nichts aus! Daher kommt es gerade (!) auf den Vortrag an (s.u.). Der enthält natürlich auch die wichtigen technischen Fakten. Bei einer Präsentation soll doch der Vortragende im Mittelpunkt stehen und nicht die Folien. Und das gelingt mit Punktlisten eben nicht, weil die Prüfer automatisch lesen, anstatt dem Prüfling zuzuhören...

Was der Bauer nicht kennt, frisst er nicht.

Ja, das ist wohl leider so. Obwohl ich bislang in der Praxis zum Zen-Stil hauptsächlich positive Rückmeldungen erhalten habe, gibt es auch noch Menschen, die die Punktlisten so gewöhnt sind und als "professionell" (alles, was bunt ist, ist wohl automatisch unprofessionell!?) ansehen, dass sie mit den "neuen" Folien nichts anfangen können.

Lieber hab ich mehrere Folien, auf denen nicht viel steht, als die Prüfer mit viel unwichtigem Input zu langweilen.

Genau mein Reden!

Ich behaupte sogar, dass der Vortragende, wenn er seine originelle Präsentation im Kopf hat und voll hinter ihr steht, wesentlich sicherer ist als jemand, der von einem Ratschlag zum nächsten eiert und aus 10 Vorlagen seinen Flickenteppich zusammenschustert, nur um es jedem recht zu machen.

Auf jeden Fall! Denn durch die Zen-Folien, auf denen eben nicht jeder Satz, den man sagen will, halb oder als Stichwort steht, ist man gezwungen, seinen Vortrag mehrmals zu üben (!) und wird somit automatisch sicherer und damit professioneller und überzeugender. Und das in Verbindung mit der vollen Aufmerksamkeit der Prüfer führt dann zu einem besseren Ergebnis...

Ich habe mir mal die Mühe gemacht und auf die Schnelle eine kleine (nicht ganz ernst gemeinte) Präsentation zum Vorher-/Nachher-Vergleich erstellt (siehe Anhang). Wenn mir jemand ein besseres (schwerer zu visualisierendes!?) Thema stellt, versuche ich mich gerne auch daran.

Es sei darauf hingewiesen, dass diese Präsentation nur ein Beispiel ist und ich sie so sicherlich nicht halten würde. Sie soll nur die zentralen Unterschiede der diskutierten Ansätze verdeutlichen und ist nicht als fertiges Produkt zu sehen.

Die zentralen Punkte:

• Keine Standardvorlage, sondern individuelles Design
  
• Jegliche Ablenkung oder Redundanz vermeiden: keine Fußzeile, kein Logo, keine Seitenzahl etc.
  
• Agenda weglassen: bei 15 Minuten kann sich wohl jeder merken, was gerade gesagt wurde
  
• Anstatt weniger Folien mit viel Text und langer "Laufzeit" viele Folien mit wenig Text und kurzer "Laufzeit", wobei dem Vortragenden die Aufmerksamkeit der Zuhörer sicher ist, da die Folien nicht ablenken, sondern schnell erfassbar sind
  

Fühlt euch hiermit aufgerufen, mich (oder besser die Präsentation ) auseinanderzunehmen!

FIAEnormal.pdf

FIAEZen.pdf