Machen Sie doch mal eben schnell!
„Ich dachte nur, dass es irgendwo auf dieser Erde ein Projekt gibt, das auf Qualität statt Zeit setzt. Aber das wäre wohl zu schön, um wahr zu sein!“ So spricht in Tom de Marcos berühmtem Projektmanagement-Roman „Der Termin“ der Chefentwickler zu seinem Projektleiter, nachdem er erfahren hat, dass die Deadline für das Projekt erneut nach vorne geschoben werden soll. Dass Zeit Geld ist wissen wir alle schon lange – also scheint es ganz natürlich, sich zu bemühen, ein Projekt so schnell wie möglich abzuwickeln. Dass schnell abgewickelte IT-Projekte jedoch nicht immer eine hohe Qualität aufweisen können, wissen wir auch.
Meistens läuft es so ab (oder so ähnlich): Der Auftraggeber erzählt einem Fachmann, welche Anforderung er an die neue Software hat, der Fachmann macht sich ein paar Gedanken und sagt dem Auftraggeber dann, wie lange er voraussichtlich für die Umsetzung brauchen würde. Der Auftraggeber akzeptiert entweder die Schätzung des Fachmanns (er ist ja schließlich der Fachmann!) oder er sagt „Das kann doch nicht sein, dass das wieder so lange dauert! Das muss doch schneller gehen!“
Was nun passiert, ist grundlegende Logik: Wenn die Anzahl der Features gleich bleibt, die Zeit aber verringert wird, dann muss woanders gespart werden. Zum Beispiel den Tests, weil diese meist ganz zum Schluss erfolgen, wenn der Abschlusstermin schon bildfüllend am Horizont erscheint (Okay, es gibt natürlich auch testgetriebene Entwicklung – aber das praktizieren die wenigsten Softwareentwickler – wahrscheinlich, weil es ihnen zu lange dauert). Wenn man es nicht rein zufällig mit einem unglaublich brillianten Entwurf zu tun hat, der keinen Raum für Fehler lässt, dann hüpfen beim Produktivstart die Fehler durch das Programm wie wildgewordene Bettwanzen. Was folgt, ist die reinste Beschäftigungstherapie für Programmierer und Anwender: monatelanges Bugfixing.
Warum müssen IT-Projekte denn nun eigentlich immer so schnell umgesetzt werden obwohl insgeheim jeder um die Nachteile dieser Vorgehensweise weiß? Grund 1: (natürlich) finanzielle Gründe, denn Entwicklungszeit kostet, Grund 2: es weiß eben nicht jeder. Gerade in der Geschäftsführeretage wird die Komplexität von IT-Projekten scheinbar oft unterschätzt. Die Damen oder Herren kennen es schließlich so, dass alles „auf Knopfdruck“ funktioniert – der Aufwand der code-, server- oder datenbankseitig dahinter steckt, ist für den User halt nicht sichtbar. Zeitschätzungen von IT-Mitarbeitern werden so einfach ignoriert oder mit dem Angebot, zusätzliche Personalressourcen für das Projekt bereitzustellen, vom Tisch gewischt.
Wenn nur genug Leute an der Sache arbeiten, dann wird sich der neue „sportlichere“ Zeitplan jawohl einhalten lassen! Übersehen wird dabei, dass zusätzliche Ressourcen (wenn sie denn überhaupt verfügbar sind), Projekte eher verlangsamen können, als das sie nützen. Erhöhter Abstimmungsbedarf, fehlende Motivation aufgrund zu kleinteiliger Arbeitsteilung und Doppelbearbeitung sind Stichwörter, die mir hierzu spontan einfallen.
Wie sich die Geschäftsführung von unrealistischen Zeitvorgaben für IT-Projekte lösen lässt, fällt mir dagegen leider nicht spontan ein. Ein möglicher Weg wäre es vielleicht, die Auftraggeber stärker am Projekt zu beteiligen, also sie zu Projektmeetings einzuladen, wöchentliche Briefings und so weiter. Wenn sich die Geschäftsleitung ansatzweise für die IT des Unternehmens interessiert, dann sollte das so schwierig nicht umzusetzen sein. Was meint ihr?