Fashion Sale Hier klicken Strandspielzeug reduziertemalbuecher Cloud Drive Photos yuneec Learn More Eukanuba Hier klicken Fire Shop Kindle PrimeMusic Summer Sale 16
Kundenrezension

5 von 7 Kunden fanden die folgende Rezension hilfreich
4.0 von 5 Sternen Bis auf eine kleine Schwachstelle sehr gut, 27. Juni 2012
Rezension bezieht sich auf: IT-Projektmanagement: Was wirklich funktioniert - und was nicht (Galileo Computing) (Broschiert)
Das Büchlein, Taschenbuch mit rund 200 Seiten, "IT-Projektmanagement" hat mir sehr gut gefallen. Es versucht das nahezu unmögliche: Einen Überblick über das Projektmanagement in der IT zu geben und das ist dem Autoren meiner Ansicht nach - mit einer Ausnahme (siehe weiter unten) - auch gelungen.

Der Schreib- und Erzählstil ist manchmal etwas "launisch", aber gerade das macht es zur kurzweiligen Lektüre.

Die Zielgruppe des Buches sind Projektleiter, damit zähle ich nicht dazu, da ich eher Projektmitarbeiter bin als Projektleiter. Trotzdem lohnt es sich immer, einen Blick über den Tellerrand zu werfen. Und auch als Projektmitarbeiter schadet es nicht, das "grössere Ganze" zu verstehen.

In dem Buch sind neben einer generellen Erklärung, wie Projekte funktionieren und wer und wie die einzelnen Rollen in einem Projekt besetzt auch eine grosse Anzahl von sehr wertvollen Praxistipps zu finden.

Dem Umfang ist geschuldet, dass nicht auf verschiedene Projektmanagement-Methoden eingegangen wird, dafür lassen sich die Empfehlungen aber auch Methoden-übergreifend verwenden. Ein kurzer Ausflug zum agilen Projektmanagement rundet das Buch inhaltlich ab.

Was mir richtig gut gefallen hat, ist ein Phasenplan, der bei der Planung eines Projektes helfen kann.

Kommen wir zum einzigen grossen Kritikpunkt, den ich habe. Den Autoren habe ich per E-Mail informiert, aber leider noch keine Antwort bekommen.

Das, was mir nicht so gut gefällt, ist, dass es in dem Buch leider vorrangig um Softwareprojekte und dort auch nur um den Entwicklungsteil geht, meiner Erfahrung nach laufen die Soft- und Hardwareentwicklung parallel, genauso wie Performance-Tuning von beiden "Gewerken" ausgeführt wird.

Im Rahmen meiner beruflichen Laufbahn habe ich einige Projekte und Teilprojekte erfolgreich zum Abschluss gebracht. Meine Hauptarbeitsgebiete sind aber System Engineering and Administration, früher auch Database Administration, daher achte ich natürlich auch genau darauf.

Leider ist es so, dass die IT aus (wenigstens) zwei "Welten" besteht, die oft sehr getrennt von einander agieren, erst das Modell der DevOps bringt die beiden Welten zusammen. Es gibt verschiedene Anforderungen. Das Software Engineering wird meiner Erfahrung nach meist durch die Featurewünsche ("funktionale Anforderungen") der Fachabteilungen getrieben und das System Engineering durch den Stabilitätswunsch, beide Bereiche teilen sich zu dem die "non-funktionale Anforderungen", hier insbesondere, aber nicht ausschliesslich, das Performance-Tuning.

Der Systembetrieb wird bei grösseren Projekten häufig vergessen, was auch oft dazu führt, dass Projekte in diesem Bereich eine Menge Reibungsverluste haben. System Engineering steht häufig in der Wertigkeit weit hinter dem Software-Engineering. Das sind meine Erfahrungen in verschiedenen Firmen.

Die unterschiedlichen Ausrichtungen zeigen sich auch im Buch. Die Phase nach Ende des Projektes wird als "Wartung" beschrieben, für mich ist das "Betrieb".

Die Zielplattform wird erst in Phase 10 aufgebaut, das ist für mich zu spät. Ich habe schon in Projekten mit Datenbankentwicklern zu tun gehabt, die das ständige Mantra vor sich hin murmelten, dass das alles unter Oracle anders funktionieren würde, Vorgabe war DB2.

Dass ich auf dieses "Reizthema" besonders reagiere, hat nichts mit der Qualität des Buches zu tun, es ist vielmehr ein allgemeiner Umstand, den ich sehr häufig antreffe.

Anmerkung: Ich habe das Buch kostenlos als Rezensionsexemplar bekommen.
Helfen Sie anderen Kunden bei der Suche nach den hilfreichsten Rezensionen 
War diese Rezension für Sie hilfreich? Ja Nein

[Kommentar hinzufügen]
Kommentar posten
Verwenden Sie zum Einfügen eines Produktlinks dieses Format: [[ASIN:ASIN Produkt-Name]] (Was ist das?)
Amazon wird diesen Namen mit allen Ihren Beiträgen, einschließlich Rezensionen und Diskussion-Postings, anzeigen. (Weitere Informationen)
Name:
Badge:
Dieses Abzeichen wird Ihnen zugeordnet und erscheint zusammen mit Ihrem Namen.
There was an error. Please try again.
">Hier finden Sie die kompletten Richtlinien.

Offizieller Kommentar

Als Vertreter dieses Produkt können Sie einen offiziellen Kommentar zu dieser Rezension veröffentlichen. Er wird unmittelbar unterhalb der Rezension angezeigt, wo immer diese angezeigt wird.   Weitere Informationen
Der folgende Name und das Abzeichen werden mit diesem Kommentar angezeigt:
Nach dem Anklicken der Schaltfläche "Übermitteln" werden Sie aufgefordert, Ihren öffentlichen Namen zu erstellen, der mit allen Ihren Beiträgen angezeigt wird.

Ist dies Ihr Produkt?

Wenn Sie der Autor, Künstler, Hersteller oder ein offizieller Vertreter dieses Produktes sind, können Sie einen offiziellen Kommentar zu dieser Rezension veröffentlichen. Er wird unmittelbar unterhalb der Rezension angezeigt, wo immer diese angezeigt wird.  Weitere Informationen
Ansonsten können Sie immer noch einen regulären Kommentar zu dieser Rezension veröffentlichen.

Ist dies Ihr Produkt?

Wenn Sie der Autor, Künstler, Hersteller oder ein offizieller Vertreter dieses Produktes sind, können Sie einen offiziellen Kommentar zu dieser Rezension veröffentlichen. Er wird unmittelbar unterhalb der Rezension angezeigt, wo immer diese angezeigt wird.   Weitere Informationen
 
Timeout des Systems

Wir waren konnten nicht überprüfen, ob Sie ein Repräsentant des Produkts sind. Bitte versuchen Sie es später erneut, oder versuchen Sie es jetzt erneut. Ansonsten können Sie einen regulären Kommentar veröffentlichen.

Da Sie zuvor einen offiziellen Kommentar veröffentlicht haben, wird dieser Kommentar im nachstehenden Kommentarbereich angezeigt. Sie haben auch die Möglichkeit, Ihren offiziellen Kommentar zu bearbeiten.   Weitere Informationen
Die maximale Anzahl offizieller Kommentare wurde veröffentlicht. Dieser Kommentar wird im nachstehenden Kommentarbereich angezeigt.   Weitere Informationen
Eingabe des Log-ins
  [Abbrechen]

Kommentare

Kommentare per E-Mail verfolgen
Von 1 Kunden verfolgt

Sortieren: Ältester zuerst | Neuester zuerst
1-3 von 3 Diskussionsbeiträgen
Ersteintrag: 11.08.2014 12:40:58 GMT+02:00
Zuletzt vom Autor geändert am 11.08.2014 12:41:32 GMT+02:00
Betrieb hat nichts mehr mit dem Projekt zu tun. Ein Projekt ist etwas abgeschlossenes, es hat ein Anfang und ein Ende. Betrieb ist das was täglich passiert und eine unbestimmte Dauer hat. Was zum Projektleiter wieder zurückkommt ist allerdings die Wartung, falls es einen Wartungsvertrag gibt. Im Buch wird auf die Einführungsphasen (ab Seite 135) eingegangen, dazu gehört auch Phase 7 der Softwaretest (dazu gehört dass die Software auf der Zielhardware läuft), die Phase 8 Migration und die Schulung aus Phase 9. Warum sollte die Einführung vor einer dieser Phasen ablaufen? Entweder man hat ungetestete Software, das Personal ist nicht geschult oder die alten Daten sind noch nicht vorhanden.

Antwort auf einen früheren Beitrag vom 11.08.2014 15:22:52 GMT+02:00
Dirk Deimeke meint:
Das war sicherlich einmal so. Im Rahmen von agilem Projektmanagement werden Teile des fertigen Produkts bereits in den Betrieb übergeben und damit wird der Betrieb zwangsweise ein Teil des Projektes. Rückkopplungen sind möglich und sogar erwünscht.

Antwort auf einen früheren Beitrag vom 26.08.2014 13:30:14 GMT+02:00
Zuletzt vom Autor geändert am 27.08.2014 14:06:05 GMT+02:00
Philon meint:
"Das war sicherlich einmal so": Nein es ist immer noch so. Eigentlich spielt es keine Rolle, ob klassische oder agile Methoden eingesetzt werden. Was ist denn Betrieb genau? Oder ein fertiges Produkt, das auch Teil eines neuen Projektes ist? Ein Beispiel hier: es gibt Unternehmen, die eine Core-Applikation haben, sagen wir ein CMS-System. Der Kunde wünscht sich eine Web-Applikation mit diversen Extras. Das CMS muss dafür entsprechend angepasst werden. Backend, Frontend, etc. müssen entsprechend angepasst werden. Wenn wir beim agilen PM bleiben: in dem Fall werden User-Stories dafür geschrieben, einmal für das Core-System und einmal für das Kundenprodukt. Denn am Ende wird die Core-Version+1 ausgerollt. Letztendlich haben wir zwei Projekte wieder am Start. Nur mit dem Unterschied, dass die Implementierungen für das Core-System keinem eigenständigen Projekt zugeordnet werden, und warum? Weil das jemand so entschieden hat und nicht weil es so richtig ist. Und das gilt in der Regel für kleinere Unternehmen, Startups bzw. Unternehmen mit niedriger Reife (Maturity Level). Mal so nebenbei 50.000 LOCs zu schreiben und das ohne Projekt? Und wie soll man dann etwas messen bzw. Code-, QA-, Projekt, und Produktmetriken daraus ableiten, wenn das fertige Produkt ein Teil des Projekts ist? Der Kunde zahlt für sein Projekt, insofern was soll der Kunde am Ende zahlen, wenn ein Teil des Projekts nicht in Rechnung gestellt werden kann, weil dies zur Betrieb gehört? (und doch kein Teil vom Projekt ist?)

Auch bei internen bzw. eigenen Produkten verhält sich genauso:wenn ein neues Feature oder ein neues Modul implementiert wird; die Schnittstellen des Produkts müssen ebenfalls angepasst werden, klar, nicht immer. Dennoch wie soll man die Dingen trennen? Was wäre "reines" Projekt hier und was Betrieb bzw. ein Teil des Projekts? Ein Projekt hat ein Ende, die neue Version, ein Update bzw. ein Hotfix, etc. wird ausgerollt. Alles was danach kommt gehört zum Betrieb. Neue User Stories sind gewiss Teil eines Projekts. Es kann auch sein, dass das ganze Jahr ein Projekt ist und die entsprechenden Iterationen Unterprojekte sind. Die Trennung aber zwischen Projekt, Betrieb und Wartung ist existent, offiziell betrachtet (nach den Standards).

Der Aussage "Leider ist es so, dass die IT aus (wenigstens) zwei "Welten" besteht, die oft sehr getrennt von einander agieren, erst das Modell der DevOps bringt die beiden Welten zusammen." stimme ich nicht zu. Ich habe oft festgestellt, dass die Zuneigung zum eigenen Beruf die Sicht der Dinge färbt. Gewiss ist die heutige IT-Landschaft komplexer geworden und seitdem sind gewisse Bereiche wichtiger geworden. Finanzunternehmen z.B. haben einiges zu tun, was die Systeme betrifft (load balancing, firewalls, DDos-Abwehrmechanismen, Performance, etc.) Vor ein paar Jahren gab es nur den Dev oder den Op sozusagen, und einige Jungs vom Build & Deployment oder von der IT waren kompetent genug, motiviert und hatten super Arbeit geleistet. Und in anderen Unternehmen lief es so: "nein, ich bin nur für das deployment zuständig, nee, das ist nicht meine Arbeit...das soll die IT machen...."

Was ich damit sagen will ist: Das größte Problem hier sehe ich bei der effektiven Umsetzung der Dinge.Ich höre immer wieder Sätze: "wir brauchen einen Businessanalyst, oder einen Changemanager, Riskmanager, oder was auch immer. All diese "neuen" Bezeichnungen umfassen nichts neues, sondern sie sind aus der Notwendigkeit entstanden, da Anforderungen jeglicher Art(Risk-, Change- und Konfigurationsmanagement, etc.) nicht richtig angepackt wurden. Businessanalyse, Steakholderanalyse, Riskmanagement, etc. gehören zun den Aufgaben eines Projektmanagers. Wenn er kompetent genug ist, dann kann er diese Dinge mit Links meistern. Fakt ist leider, dass die Lage hier sehr defizitär ist, deshalb finde ich es auch gut, dass solche Spezialisten eingekauft werden.
‹ Zurück 1 Weiter ›