Umgang mit gefundenen Fehlern in der Projektdokumentation während der Projektpräsentation

Bei der Erstellung der Projektpräsentation taucht bei vielen Azubis oftmals die folgende Frage auf:

Soll ich gefundene Fehler in meiner Projektdokumentation in der Projektpräsentation erwähnen (und korrigieren)?

In der (teils sehr langen) Zeit zwischen der Erstellung der Projektdokumentation und der Vorbereitung der Projektpräsentation fallen vielen Prüflingen beim erneuten Lesen ihrer Ausarbeitung häufig doch noch einige Fehler auf, die ihnen bei der finalen Korrektur durch die Lappen gegangen sind. Sollen diese Fehler nun in der Projektpräsentation erwähnt und korrigiert werden?

Die kurze Antwort: Es kommt drauf an 😉

Um welche Fehler geht es hier?

Es geht natürlich nicht um Rechtschreibfehler oder andere Trivialitäten. Wenn die in der Projektpräsentation korrigiert werden müssten, würde bei den meisten Prüflingen keine Zeit mehr für den eigentlichen Inhalt bleiben 😉

Ich spreche hier z.B. von Rechenfehlern bei der Kalkulation, Planungsfehlern in der Zeitplanung, vergessenen Ressourcen oder Arbeitsstunden der Projektmitarbeiter, fehlenden Informationen über verwendete Frameworks oder Bibliotheken, nicht eingefügten Diagrammen usw.

Es geht also um Fehler, die ggfs. eine andere Einschätzung und Bewertung des Projekts zur Folge hätten.

Jeder Mensch macht Fehler

Vorweg: Niemand ist unfehlbar. Fehler passieren. Und (gerade) auch in der Projektdokumentation.

Grundsätzlich ist es kein Problem, wenn Fehler in der Projektdokumentation auftauchen. Das Schlimmste, das passieren kann, ist eine Abwertung der Dokumentation. Aber dafür müssen schon mehrere Punkte zusammenkommen. Also gilt erstmal: Ruhe bewahren.

Nur weil ein paar Zahlen falsch sind oder ein Diagramm fehlt, wird die Dokumentation nicht mit „ungenügend“ bewertet (was die Horrorvorstellung vieler Prüflinge nach dem Entdecken der Fehler ist). Ich sage nicht, dass man trotzdem noch ein „sehr gut“ bekommt, aber für eine deutliche Abwertung der Dokumentation müssen schon mehrere Fehler zusammenkommen.

Soll ich in der Projektpräsentation auf meine Fehler hinweisen?

Grundsätzlich gilt: Mit der Wahrheit fährt man immer am besten. Die Prüfer sind nicht dumm und prüfen die Dokumentation auf Herz und Nieren. Gerade Rechenfehler fallen ihnen sicher auf, da insb. die Kalkulation meist intensiv geprüft wird.

Wer also vorhat, die Fehler stillschweigend zu ignorieren oder gar zu leugnen, der tut sich damit keinen Gefallen. Fehler sind nur dann ein Problem, wenn man nicht aus ihnen lernt. Seht das Ganze wie im echten Leben: Wenn eure realen Projekte nicht laufen, müsst ihr das eurem Chef auch so schnell wie möglich beichten, damit noch gegengesteuert werden kann. Alles andere wäre fahrlässig.

Das bedeutet aber nicht, dass eure Präsentation nur aus Rechtfertigungen und Hinweisen auf eure schlechte Arbeit bestehen sollte. Ihr zieht eure Präsentation einfach durch und erwähnt an den entsprechenden Stellen in einem Nebensatz euren Fehler in der Präsentation.

Die fehlerhaften Teile sind Bestandteil der Projektpräsentation

Die erste Frage, die ich mir stellen würde, ist, ob die fehlerhaften Teile der Projektdokumentation ohnehin in der Projektpräsentation erwähnt worden wären. Handelt es sich z.B. um einen Rechenfehler in der Wirtschaftlichkeitsbetrachtung, so ist dies ein zentraler Bestandteil jeder Präsentation. Das bedeutet, ihr müsst die Prüfer darauf hinweisen, wenn ihr einen Fehler entdeckt – und noch wichtiger: auch korrigiert – habt.

Andernfalls würdet ihr in der Präsentation z.B. mit anderen Zahlen rechnen als in der Dokumentation und ggfs. zu anderen Ergebnissen kommen. Die Prüfer, die die Dokumentation gelesen haben, werden sich dann zurecht fragen, wieso auf einmal ein anderes Ergebnis herauskommt.

Ignoriert ihr stattdessen euren Fehler und arbeitet mit den gleichen Werten aus der Dokumentation, ist die Chance groß, dass der Fehler entdeckt wird und zu interessanten Fragen im Fachgespräch führt. Natürlich könnt ihr dann sagen, dass der Fehler euch nicht aufgefallen ist, aber das spricht nicht gerade für eure Arbeit. Denn zweimal den gleichen Fehler zu machen – in der Projektdokumentation und erneut bei der Erstellung der Projektpräsentation, für die man den Stoff eigentlich noch einmal intensiv aufbereitet – deutet auf eine fehlende Qualitätssicherung hin.

Ich würde also dringend dazu raten, gefundene Fehler anzusprechen und gleich zusätzlich auf die Korrektur und die Auswirkungen auf das Projekt einzugehen, z.B. so:

Das Projekt hat insg. Kosten von 4.000 Euro verursacht. In die Projektdokumentation hat sich leider ein Rechenfehler eingeschlichen, sodass dort mit 3.500 Euro gerechnet wurde. Trotzdem amortisiert sich das Projekt noch innerhalb der geplanten 2 Jahre.

Oder ein anderes Beispiel:

In der Projektdokumentation habe ich leider vergessen zu erwähnen, dass ich mit ActiveRecord gearbeitet habe, um den Datenbankzugriff zu vereinfachen. Das ist Grund, warum meine Implementierungsphase für die Datenbankanbindung nur 1 Stunde gedauert hat. Dies hat allerdings keine Auswirkung auf den weiteren Projektablauf, der wie geplant durchgeführt wurde.

Die fehlerhaften Teile werden nicht in der Projektpräsentation erwähnt

Etwas anders verhält es sich, wenn die fehlerhaften Teile eurer Dokumentation gar nicht in der Projektpräsentation auftauchen sollen. Habt ihr z.B. einen Fehler in der Implementierung eures Unit-Tests gefunden, aber zeigt den Quelltext gar nicht in der Präsentation, gibt es auch keinen Grund, den Fehler anzusprechen.

Man sollte sich als Prüfling natürlich von seiner besten Seite zeigen und nicht die Teile der Projektarbeit hervorheben, die nicht gut gelaufen sind. Die Auswahl der interessanten und positiven Inhalte der Projektarbeit ist wichtiger Bestandteil des Prozesses zur Erstellung der Projektpräsentation. Niemand wird in der Projektpräsentation eine Liste aller gefundenen Fehler erwarten.

Bereitet euch aber bei allen gefundenen Fehlern auf Rückfragen im Fachgespräch vor. Fehler sind natürlich ein guter Einstiegspunkt in eine spannende Diskussion mit dem Prüfling 🙂 Überlegt euch schon vorher eine vernünftige Argumentation, falls ihr auf den Fehler angesprochen werdet, z.B.

Ja, den Fehler habe ich auch schon entdeckt. Er ist inzwischen im Programm behoben und die Software läuft korrekt. Dies haben auch die Benutzertests bestätigt. Dadurch wurde mir wieder einmal die Wichtigkeit von Unit-Tests bewusst, die diesen Fehler wahrscheinlich direkt aufgedeckt hätten. Alternativ hätte vielleicht ein Code-Review den fehlerhaften Code identifiziert. Das werde ich auf jeden Fall bei meinen zukünftigen Projekten berücksichtigen.

Wichtig dabei ist: Ihr solltet das, was ihr sagt, auch ernst meinen und nicht nur den Prüfern nach dem Mund reden. Seht jeden Fehler als potentielle Verbesserung eurer zukünftigen Arbeit!

Fazit

Fehler macht jeder. Aber das ist erst dann ein Problem, wenn man nicht aus ihnen lernt. Also geht offen mit euren Fehlern in der Projektdokumentation um und korrigiert sie in der Projektpräsentation.

Das bedeutet jedoch nicht, dass der Fokus auf euren Fehlern liegen sollte. Zeigt einfach, dass ihr etwas gelernt habt und behandelt die Fehler als das, was sie sind: ein normaler Bestandteil der Projektarbeit.

Wie seht ihr das? Habt ihr Fehler in eurer Dokumentation „gestanden“? Oder habt ihr sie verheimlicht? Wie ist das Ganze für euch ausgegangen?

Weitere Infos zur Projektpräsentation

Du suchst noch mehr Tipps rund um die Projektpräsentation? Dann schau doch mal in diese Artikel- und Podcast-Kategorie: Alle Artikel rund um die Projektpräsentation.

Und wenn du dich für meinen Newsletter einträgst, kannst du dir jetzt sofort meine Checkliste für die Projektpräsentation herunterladen.

Checkliste für die Projektpräsentation

Jetzt anmelden!

Polyglot Clean Code Developer
About the Author
Ausbildungsleiter für Fachinformatiker Anwendungsentwicklung und Systemintegration, IHK-Prüfer und Hochschuldozent für Programmierung und Software-Engineering.

4 comments on “Umgang mit gefundenen Fehlern in der Projektdokumentation während der Projektpräsentation

  1. EinfachE sagt:

    Hi, ich habe beim Erstellen bei meiner Präsentation gerade gemerkt, dass ich in meinem Use-Case-Diagramm vieles falsch gemacht habe (eine Bedingung als Use-Case dargestellt, manche Use-Cases keinem Akteuer zugeordnet, zu viele include Beziehungen glaube ich,…) .Ich habe sonst noch: Programmablaufplan, Aktivitätsdiagramm, Mockup, ER-Modell, Datenbankstruktur (Screenshot), Auszüge aus der Kunden- und Entwicklerdoku, Auszüge aus dem Code und andere Screenshots von der fertigen Anwendung zu zeigen.
    Soll ich das Use-Case-Diagramm einfach weglassen, mich nur auf einen konkreten Ausschnitt (der einigermaßen richtig sein sollte) beschränken oder das ganze Use-Case-Diagramm zeigen? Ich würde es lieber ganz weg lassen wollen, aber bin mir nicht sicher, ob mir dann ein wichtiges Artefakt fehlt, wenn man bedenkt, dass ich bei anderen Artefakten (wie PAP oder UML-Aktivitätsdiagramm) auch nicht 100% sicher bin.
    Wie gehen Prüfer eigentlich generell mit Fehlern in Artefakten z.B. in der Dokumentation um?

  2. Stefan Macke sagt:

    Genau diese Frage habe ich doch oben beantwortet! 🙂 Zeig das Use-Case-Diagramm (wichtiges Artefakt!) und erkläre, dass du im Nachhinein Fehler entdeckt hast, die du für die Präsi nun korrigiert hast.

  3. EinfachE sagt:

    Hi Stefan, wie gehen Prüfer bzw. wie gehst du damit um, wenn gezeigte Artefakte in der Dokumentation oder Präsentation viele Fehler enthalten oder sogar ganz falsch sind? LG

  4. EinfachE sagt:

    …bei der Bewertung/Benotung meine ich. Ich habe bereits gesehen, dass du schon etwas dazu oben im Artikel geschrieben hast, aber ich frage mich dennoch, ob man eine ganze Note abgezogen bekommt für ein fehlerhaftes Artefakt…

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

To create code blocks or other preformatted text, indent by four spaces:

    This will be displayed in a monospaced font. The first four 
    spaces will be stripped off, but all other whitespace
    will be preserved.
    
    Markdown is turned off in code blocks:
     [This is not a link](http://example.com)

To create not a block, but an inline code span, use backticks:

Here is some inline `code`.

For more help see http://daringfireball.net/projects/markdown/syntax