Klenner95 Geschrieben 18. Januar 2018 Geschrieben 18. Januar 2018 Hallo, mein Abschlussprojekt soll ein Upgrade von Loadbalancer auf eine Neue Version sein. Die Loadbalancer sind im Wirknetz eingesetzt. Und Somit ist das Upgrade auch mit Risiko verbunden. Die eigentliche arbeit wären dann die Vor- und Nachprüfungen. Wäre das geeignet? Vielen dank für die Hilfe Zitieren
Nopp Geschrieben 18. Januar 2018 Geschrieben 18. Januar 2018 Also theoretisch ist es am Ende aber nur ein weiter-weiter klicken? Zitieren
Klenner95 Geschrieben 18. Januar 2018 Autor Geschrieben 18. Januar 2018 Nein es wird über die Konsole getestet und ausgeführt. Zitieren
Nopp Geschrieben 18. Januar 2018 Geschrieben 18. Januar 2018 Das meine ich nicht. Ein Update ist am Ende nichts weiter als das stumpfe Ausführen eines Leitfadens des Herstellers. Das wird in den meisten Fällen abgelehnt werden, weil die fachliche Tiefe einfach nicht gegeben ist. Wo ist die wirtschaftliche Betrachtung, wie eine Kosten-Nutzen Analyse? Wo der Vergleich mit anderen Lösungen? Das liest sich für mich mehr als fester Auftrag, den man einfach abarbeitet. Zitieren
Klenner95 Geschrieben 18. Januar 2018 Autor Geschrieben 18. Januar 2018 Ja das Update wäre nur Ausführen ein Leitfadens. Aber bei dem Projekt geht ja auch auch um das Testen im vorfeld und im nachgang. Die Tiefe kommt ja eher durch Kenntnisse die man haben muss, um die Tests auswerten zu können. Es müssen Routen überprüft werden, es muss Überprüft werden ob die Session aufgebaut werden können und ob die Beiden LB auch wieder Synchron laufen. Der vergleich mit anderen Lösung würde durch einen Vergleich der Version machen und bei der Kosten Analyse gibt nur Personalkosten da es einen Vertrag mit dem Hersteller gibt. Zitieren
Nopp Geschrieben 18. Januar 2018 Geschrieben 18. Januar 2018 Schreib am besten mal einen Projektantrag und poste den hier... Anschließend kann man schauen. Ich denke aber persönlich dass das Ausführen eines Updates zu wenig ist, auch wenn man es vorher testet und im Anschluss Revue passieren lässt. Zitieren
cortez Geschrieben 18. Januar 2018 Geschrieben 18. Januar 2018 vor 30 Minuten schrieb Nopp: Wo ist die wirtschaftliche Betrachtung, wie eine Kosten-Nutzen Analyse? Wo der Vergleich mit anderen Lösungen? Das liest sich für mich mehr als fester Auftrag, den man einfach abarbeitet. So ziemlich genau das. Da es einfach nur ein Upgrade ist, fehlt von deiner Seite aus jede Entscheidung. Es liest sich wie @Nopp schon gesagt ehr als Arbeitsauftrag. Zitieren
Goulasz Geschrieben 18. Januar 2018 Geschrieben 18. Januar 2018 (bearbeitet) Hallo @Klenner95! Etwas grundsätzliches zur Unterscheidung zwischen Projekt und Prozess. Es ist ein bisschen was zu lesen, aber für alle zukünftigen Probleme und deren Analyse relevant. Ein Projekt ist durch seine Einmaligkeit gekennzeichnet. Es enthält überwiegend komplexe Merkmale, also potentielle Überraschungen und Wendungen, denen man mit neuem Können begegnen muss. Für das Problem gibt es noch kein verfügbares Wissen, weder in der eigenen Firma, noch außerhalb. Ein Prozess zeichnet sich durch seine für den Kontext gegebene Gültigkeit und Wiederholbarkeit aus. Er ist durch Wissen beschrieben, also nicht komplex sondern kompliziert. Ist das Wissen noch nicht im eigenen Unternehmen vorhanden, benötigt es neben der Beschaffung des Wissens einen neuen Prozess, aber kein Projekt. Zur Unterscheidung "komplex" vs "kompliziert" gibt es hier ein sehr schönes, circa 15-minütiges Video von Harald Lesch in der ZDF-Mediathek. Es handelt sich bei dem hier beschriebenen Problem nicht um ein "ungelöstes" Thema. Nur weil ihr das Wissen (noch) nicht in der Organisation habt, heißt das nicht, dass es ein neues Problem ist, für das es ein Projekt benötigt. Wenn sich jemand das Wissen aneignet, kann er den Prozess zur Umstellung befolgen, dafür benötigt es kein Projekt. Für viele Probleme werden Projekte aufgesetzt, obwohl es das Wissen zur Lösung bereits gibt, nur eben noch nicht in der Firma. Ein Projekt ist für so einen Fall "mit Kanonen auf Spatzen schießen". Am anderen Ende des Spektrums hast du dann Leute, die tatsächliche neue Probleme mit vorhandenem Wissen lösen wollen, was ebenso schlecht funktioniert. In deinem Fall sind sowohl die Ausgangslage als auch das angestrebte Arbeitsergebnis schon vor Beginn deiner Tätigkeit definiert. Das von dir angesprochene Risiko erhöht in einer "normalen" IT-Infrastruktur nur den Grad der Kompliziertheit und bringt keine echte Komplexität. Es ist in der Regel überschau- und planbar. Die Komplexität kommt ggfs. bei einer gewachsenen Konzern-Infrastruktur mit Legacy-Systemen ohne Dokumentation und so vielen Wirkzusammenhängen, dass die Kompliziertheit nicht mehr von Menschen überschaubar ist. In so einem Fall, der ein Grenzbereich ist, könnte auch bei IT-Systemen imho von "echter" Komplexität sprechen. TL;DR: Verwendest du Methoden aus der Domäne "Projekt" für einen Prozess, verschwendest du im günstigsten Fall nur Zeit. Verwendest du Methoden aus der Domäne "Prozess" für ein Projekt, riskierst du, das Problem nicht richtig zu identifizieren und die Ursache nicht zu lösen. Gruß, Goulasz P.S.: Die meisten Probleme sind nicht rein binär "komplex" oder "kompliziert", sondern haben Anteile beider Domänen. Hier ist es wichtig, vor Beginn der Bearbeitung durch eine Problemtransformation die Anteile klar zu trennen, um sich einen Überblick zu verschaffen. Dazu gibt es hier einen schönen Denkzettel auf dem Blog von Gerhard Wohland, dessen Buch "Denkwerkzeuge der Höchstleister" ich hier auf dem Blog schon vorgestellt habe. Bearbeitet 18. Januar 2018 von Goulasz Typos, P.S. zur Klärung hinzugefügt thereisnospace reagierte darauf 1 Zitieren
Empfohlene Beiträge
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.