Zum Inhalt springen

Projektantrag: Implementierung einer Verwaltung für Verleihaufträge eines Sportgeräteverleihs für Winter- und Wassersportartikel


blobe

Empfohlene Beiträge

Liest sich erstmal gut! Folgendes fällt mir auf:

  • Mir fehlt die Amortisationsbetrachtung.
  • Dass du (wahrscheinlich) mit PHP arbeitest, wird nur deutlich, wenn man TYPO3 kennt.
  • Puffer würde ich komplett rausnehmen.
  • Gibt es keine Kundendokumentation?

 

Bearbeitet von stefan.macke
Artefakte übersehen
Link zu diesem Kommentar
Auf anderen Seiten teilen

Hallo Stefan,

danke für die Rückmeldung, zu Deinen Punkten:

  • Die Amortisationsprüfung ist nun in der Planung unter Phase A – Planung zu finden
  • Nun zu finden unter 9. Notwendige technische Einrichtung/Werkzeuge
  • Den Puffer habe ich nun rausgelassen und die Stunden verteilt (mein AWE Lehrer, Prüfer bei der IHK, hat uns allerdings ans Herz gelegt einen Puffer einzubauen)
  • Die Erstellung der Kundendoku ist in der Planung unter Phase D - Dokumentation zu finden

Die überarbeitete Version im Anhang.

Projektantrag.pdf

Link zu diesem Kommentar
Auf anderen Seiten teilen

blobe, das ist eine eigene Meinung deines AWE-Prüfers. Uns wurde eingehämmert, dass wir keinen Puffer einbauen sollen, da die Stunden leicht zu verteilen ist und man mit guten Argumenten problemlos in der Doku hin und her schieben kann(sollte sich dennoch in Grenzen halten).

Ein Puffer sagt aus, dass du nichts mit der Zeit anzufangen weißt und nicht korrekt mit deinem Zeitmanagement planen kannst. Ein Puffer sollte laut Prüfern der IHK-Nürnberg(und wahrscheinlich vielen anderen, wie in diesem Forum deutlich wird) nichts in dem Projekt zu suchen haben.

Link zu diesem Kommentar
Auf anderen Seiten teilen

Ich hatte auch einen Puffer drin und bei uns war es absolut kein Problem, ich hab halt direkt dazu geschrieben das der Puffer für mögliche Fehlerkorrekturen und Nachbesserungen bzw. Änderungswünsche ist nachdem die Funktionalität getestet wurde von den Betroffenen Abteilungen. Mir wurde immer beigebracht ein Puffer (solange er realistisch ist und sich in Grenzen hält) ist nie was schlechtes, er zeigt nur das man gerade bei neuen Dingen vorsichtig ist und lieber ein wenig mehr plant das man dann streichen kann wenn es doch nicht benötigt wird bzw. es eben im Laufe des Projekts auf den Punkt ummünzen kann der etwas mehr Zeit benötigt, einen Kunden freut es am Ende immer mehr wenn er doch weniger Zahlen muss falls der Puffer nicht benötigt wird.

Also daher sehe ich einen Puffer nie als was schlimmes, er sollte aber direkt mit einem kleinen Hinweis versehen werden für was er möglicherweise gebraucht wird. Einfach nur "Puffer" hinschreiben is eher ungünstig. Und gerade wenn man etwas macht das möglicherweise Änderungen unterläuft, ist es meiner Meinung nach eher schlecht direkt 8 Stunden mehr für die Testphase oder Entwicklung einzuplanen, weil ja mögliche Änderungen oder Fehler gefunden werden könnten die mehr Zeit in Anspruch nehmen oder auch nicht, da schreibe ich lieber gleich dazu das es ein Puffer ist der sich umverteilen lässt bzw. gestrichen werden kann, wie gesagt Kunden haben sich eher gefreut wenn sie gesehen haben da könnten sie was sparen bzw. direkt wussten wenn sie doch Änderungswünsche haben ist dafür auch schon Zeit eingeplant und es kommt nicht am Ende doch noch eine größere Rechnung. Ich halte das für bessere Planung als erstmal fest davon auszugehen das die ganze Zeitplanung perfekt funktioniert, ich hab in der Ausbildung einfach gelernt durch viele verschiedene Kunden, es kann immer noch etwas kommen das nicht geplant war bzw. das doch anders gemacht werden soll und dann is man über jeden Puffer dankbar, den man in weiser Vorraussicht schon eingeplant hat und über den der Kunde Bescheid weiß so das ich später nicht erklären muss warum ich jetzt doch mehr Zeit benötigt habe.

Aber ich denke das macht jeder wie er will und da scheiden sich sicher die Geister. Wie es immer ist, wird das denke ich auch von IHK zu IHK unterschiedlich gewertet, die eine sieht es negativ, die andere interessiert es nicht und die letzte kann den Gedankengang viellicht nachvollziehen.

Link zu diesem Kommentar
Auf anderen Seiten teilen

Tätigkeiten sollten allgemein so geplant werden, dass ein Puffer innerhalb dieser enthalten ist. Diesen explizit anzugeben halte ich auch für unnütz, wenn nicht sogar schlecht.

Sollten sich die Zeiten deiner Planung mit denen der Durchführung nicht decken(und im Rahmen liegen), kannst du dies in deiner Dokumentation anbringen und begründen. Es gibt in Projekten mit großer Komplexität(sprich: Überraschungen, nicht planbares, viele Schnittstellen zu "Menschen") immer Umplanungen, weswegen das Verwenden eines expliziten Puffers meines Erachtens nach zu vermeiden ist.

Grundsätzlich: Änderungen im Projektverlauf können bei komplexen Umfeldern immer passieren. Wenn du in der Doku und Präsentation zeigst, woher die kamen und dass du damit umgehen kannst, ist es kein Hinderungsgrund für ein "sehr gut", auch bei Abweichungen. 


Gruß, Goulasz

Link zu diesem Kommentar
Auf anderen Seiten teilen

Naja wie gesagt ich habs anders beigebracht bekommen und hatte damit in der Ausbildung und mit allen Kunden mit denen ich zutun hatte, nie Probleme. Auch bei meinem Projektantrag und dem Projekt selbst zum Ende hin gabs da nie Probleme. Ich schildere hier nur meine Erfahrung/Meinung dazu, als kleinen Kontrast zu dem "Nein, Nein, Nein Puffer böse" ;) Ich denke das kommt wie schon vorher erwähnt wie viels einfach drauf an in welchen Betriebt, welche IHK usw. je nachdem wird das sich unterschiedlich gesehen und ich kann halt nur von meinen Erfahrungen berichten :)

Bearbeitet von Albi
Link zu diesem Kommentar
Auf anderen Seiten teilen

Hallo Albi!

Spinn den Gedanken mal weiter. IHK hin oder her.

Du erstellt ein Angebot für einen Kunden, ein Projekt mit einem Volumen von $lächerlichViel Mannstunden. Darin enthalten ist ein Puffer, der explizit aufgeführt ist. Der Kunde bezahlt dich also im günstigsten Fall des Projektverlaufs(Puffer wird nicht benötigt) für's Nichtstun. Mir als Auftraggeber würde das sauer aufstoßen.

Allgemein halte ich in Projekten, in denen abzusehen ist, dass es viele Überraschungen und Änderungen geben kann/wird, wenig von einer expliziten, festen Zeitplanung(Wasserfall, GANTT) und bin eher auf der Seite iterativer Vorgehensmodelle(z.B. SCRUM, Lean Startup, MVPs, etc.).

Dieser Fakt, der einem in der Realität als Entwickler, der in Projekten arbeitet, permanent unterkommt, wird leider aufgrund der Struktur des Abschlussprojektes und der Limitation auf 70 Stunden in der Prüfung völlig ignoriert.

Gruß, Goulasz

Link zu diesem Kommentar
Auf anderen Seiten teilen

vor 23 Minuten schrieb Goulasz:

Du erstellt ein Angebot für einen Kunden, ein Projekt mit einem Volumen von $lächerlichViel Mannstunden. Darin enthalten ist ein Puffer, der explizit aufgeführt ist. Der Kunde bezahlt dich also im günstigsten Fall des Projektverlaufs(Puffer wird nicht benötigt) für's Nichtstun. Mir als Auftraggeber würde das sauer aufstoßen.

Da hast du wohl meinen ersten Beitrag nicht richtig gelesen ;) Denn den Puffer bezahlt er ja nicht wenn er nicht benötigt wird, somit hat er im besten Fall eine Kostenersparnis, wenn der Puffer benötigt wird, wird er aber auch nicht überrascht davon. Wie gesagt während meiner Ausbildung in 3 Jahren bei vielen Themen und den verschiedensten Kunden praktiziert mit meiner Ausbildungsfirma und es hat sich nie jemand beklagt über den explizit angegebenen Puffer, da er immer vorher begründet wurde und eben mit der Aussicht, wenn er nicht verwendet wird, muss er nicht bezahlt werden, das freut die Kunden.

Bearbeitet von Albi
Link zu diesem Kommentar
Auf anderen Seiten teilen

Habe ich tatsächlich überlesen. Explizit angeben würde ich ihn trotzdem nicht. In Projekten in denen klar ist, dass es vermutlich Nachplanungen gibt, bietet sich ein entsprechendes Vorgehensmodell an. In Projekten, die durchgeplant werden, geht ja aus der "Planung" hervor, dass die komplizierten Anteile überwiegen und nicht die komplexen. Das lässt sich mit Wissen und Erfahrungswerten recht genau beschreiben und ein "Puffer" sollte eigentlich nicht nötig sein.

Ansonsten finde ich den Antrag auch gelungen. Die Aufteilung ist fein genug, es ist erkennbar, was du machst. Ich denke, einer Genehmigung zumindest bei uns (IHK Kassel/Marburg) stünde im Vergleich zu den mir bekannten Anträgen nichts im Weg. 

 

Gruß, Goulasz

Link zu diesem Kommentar
Auf anderen Seiten teilen

  • 3 Wochen später...

Dein Kommentar

Du kannst jetzt schreiben und Dich später registrieren. Wenn Du ein Konto hast, melde Dich jetzt an, um unter Deinem Benutzernamen zu schreiben.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung wiederherstellen

  Nur 75 Emojis sind erlaubt.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

Fachinformatiker.de, 2024 by SE Internet Services

fidelogo_small.png

Schicke uns eine Nachricht!

Fachinformatiker.de ist die größte IT-Community
rund um Ausbildung, Job, Weiterbildung für IT-Fachkräfte.

Fachinformatiker.de App

Download on the App Store
Get it on Google Play

Kontakt

Hier werben?
Oder sende eine E-Mail an

Social media u. feeds

Jobboard für Fachinformatiker und IT-Fachkräfte

×
×
  • Neu erstellen...