IT-Projektmanagement ...
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.
Trackbacks
Dirks Logbuch am : Wissen teilen ...
Vorschau anzeigen
Vor etwa drei Wochen bekam ich eine Mail von jemandem, der sich diese Session mit mir (Mann, war ich da noch dick) angeschaut hat und Fragen dazu hatte. Zuerst musste ich natürlich nachschauen, was ich damals "verzapft" habe. Zu den allermeisten Punkten h
Kommentare
Ansicht der Kommentare: Linear | Verschachtelt
Thomas Schnyder am :
Dirk Deimeke am :