 |
| Leitfaden zur Sabotage von IT-Projekten:
105 taffe Taktiken für Teamleiter
Teil 1
| Teil 2 | Teil
3 | Teil
4
|
| (Dezember 2005) |
|
"Das ist nur eine kleine Änderung, das kriegt Ihr zwischendurch
hin" - will heißen: eine Woche Mehrarbeit. Kommt Ihnen
irgendwie bekannt vor? Weitere Taktiken, mit denen es Teamleitern
garantiert gelingt, den Arbeitsaufwand so zu maximieren, dass das
Projektergebnis in weite Ferne rückt, lesen Sie im zweiten
Teil des Leitfadens zur Sabotage von IT-Projekten. Das Standardwerk
für sabotagewillige Projektverantwortliche entstammt der Feder
von Bernd Schulte Osthoff, zertifizierter Management-Berater und
Trainer, seit über 16 Jahren in der IT-Branche tätig.
Mit einer gehörigen Brise Ironie beschreibt er die leider noch
viel zu häufig im Projektmanagement anzutreffenden Verhaltensweisen.
|
| Jedem das Seine. |
|
| |
|
| 26) |
Der Kunde möchte, dass Sie so bald wie möglich Ergebnisse liefern.
Also weisen Sie Ihr Team an, nicht auf die Designdokumente
oder Methodikstandards zu warten und sofort anzufangen. Spaghetticode
ist hier akzeptabel.
|
| 27) |
Formale Methodiken sind unausweichlich. Der Kunde wird
danach fragen. Schicken Sie zwei aus Ihrem Team dann auf einen
Crashkurs, als Multiplikatoren für die anderen. Wählen
Sie später eine völlig andere Methodik. Sie sind
der Boss.
|
| 28) |
Ihr Team wird eigene Vorstellungen haben. Wählen Sie
eine Methodik aus und zwingen Sie alles in dieses Vorgehen.
Auch wenn die Methodik ungeeignet oder veraltet ist. |
|
| Statusmeetings für alle! |
|
| |
|
| 29) |
Verlangen Sie die Anwesenheit des gesamten Teams zu allen Statusmeetings. Das
erzeugt Gemeinschaftssinn und ist eine willkommene Abwechslung.
Auch wenn der Einzelne kein Interesse oder keinen Nutzen von
dem hat, was besprochen wird.
|
| 30) |
Wenn konkrete Probleme anstehen, fragen Sie nicht Ihr
Team nach Vorschlägen. Laden Sie zwei Experten aus anderen
Projekten ein. Die entstehenden Fachdiskussionen sind für
alle eine Bereicherung.
|
| 31) |
Vermeiden Sie es, über Anforderungsspezifikationen zu
diskutieren. Der Kunde weiß nicht, was er will. Das Team
weiß nicht, was der Kunde will. Und Sie wollen flexibel
bleiben, bis zum Projektende. |
|
| Mischen Sie sich unters Volk. |
|
| |
|
| 33) |
Werden bei einem Meeting Design- oder Codier-Fehler erwähnt, unterbrechen
Sie das Meeting und verlangen Sie die sofortige Beseitigung.
So halten Sie das Team auf Trab.
|
| 34) |
Schlagen Sie laufend Änderungen oder "interessante"
Erweiterungen vor, die der Kunde lieben wird. Keiner wird
wagen, Ihnen zu widersprechen.
|
| 35) |
Ändern Sie regelmäßig nach Feierabend die
Passwörter der Server und Entwicklersysteme. Sicherheit
geht vor. |
|
| Geschwindigkeit ist keine Hexerei. |
|
| |
|
| 36) |
Ihr Kunde liebt schnelle Systeme. Setzen Sie daher von
Anfang an die Geschwindigkeit der Software auf die oberste
Priorität. Hängen Sie überall Formel-1-Poster
auf. |
| 37) |
Lassen Sie es nicht zu, dass für Teilsysteme externe
Softwarebausteine eingekauft werden. Hier haben Sie keine
Kontrolle über die Geschwindigkeit. |
| 38) |
Wiederverwendbare Module, Objekte oder Klassen sind zu langsam.
Plan B: gründen Sie ein Design-Komitee für Wiederverwendbarkeit.
Berufen Sie Ihr ganzes Team. Das sorgt für Zeitplan sprengende
Diskussionen. |
|
| Unit-Testing geht vor. |
|
| |
|
| 39) |
Jede Unit ist vor jedem Build eingehend zu testen. Alle
Schnittstellen müssen exklusiv für den Test programmiert
werden. Alle Testergebnisse müssen vom Teamleiter geprüft
und abgezeichnet werden. Verlangen Sie ein professionelles
Dokumentations- und Ablagesystem. |
| 40) |
Treffen Sie keinerlei Vorbereitungen für Integrationstests.
Schließlich ist nicht abzusehen, wann alle Unit-Tests
abgeschlossen sind. Außerdem können Sie sich ja jederzeit
Testdaten aus anderen Projekten ausleihen, zusätzlich benötigte
Hardware beim Kunden nutzen, und jederzeit auf die Unit- und
Subsystem-Leute zurückgreifen. |
|
| Alte Hasen in Reserve. |
|
| |
|
| 41) |
Setzen Sie für die Integrationstests unbedingt jemanden
ein, der keine Ahnung von den im Projekt verwendeten Systemen
hat. Für ein Java- oder Linux-Projekt ist ein Programmierer
alter Schule ideal. |
| 42) |
Auch jemand aus dem mittleren Management ist ideal. Oder
in kleinen Firmen der Chef selbst. Diese Leute haben jahrelang
nicht mehr programmiert, erzählen aber immer gern von
den glorreichen Anfangsjahren als Programmierer. |
| 43) |
Folgende Verhaltensweisen identifizieren den idealen Integrationstester:
ist viel in der Firma unterwegs, spricht ständig mit Kreti
und Pleti, liest selten E-Mails, mag den Kunden nicht, kritisiert
ständig die Firmenpolitik. |
|
| Profis sind anpassungsfähig. |
|
| |
|
| 44) |
Lassen Sie jederzeit Änderungen zu. Change Requests
sind in Ordnung, solange sie für das Projektmanagement,
das Prozessmanagement, das Qualitätsmanagement und für
den Vorgehensmodell-Standard dokumentiert werden. |
| 45) |
Falls die Arbeit am Projekt einmal zu glatt läuft,
nutzen Sie die Zeit und schalten Sie bei ein oder zwei Änderungen
die Verantwortlichen für Projektmanagement, Prozessmanagement,
Qualitätsmanagement und Vorgehensmodell-Standard miteinander
kurz. |
| 46) |
Meilensteine sind die Ausnahme. Sie müssen eingehalten
werden. Koste es, was es wolle. Wenn zu diesem Zweck jede Menge
Provisorien eingebaut werden, um so besser. |
|
| Man muss es nur begründen können. |
|
| |
|
| 47) |
"Das haben wir doch schon längst freigegeben"
(übersetzt: "Jetzt tanz' Du nicht schon wieder aus
der Reihe.").
|
| 48) |
"Diese Änderungen sind fixiert, bekannt und dokumentiert"
(übersetzt: "Lass bloß die Finger davon.").
|
| 49) |
"Das ist nur eine kleine Änderung, das kriegt
ihr zwischendurch hin" (übersetzt: eine Woche Mehrarbeit).
|
| 50) |
"Das ist der Abschluss von Change Request Nr..."
(übersetzt: "Keiner weiß, wieso – warum
– woher").
|
| 51) |
"Das sind Fehlerkorrekturen, die erledigt ihr mit links"
(übersetzt: "WER hat denn wohl den Murks produziert,
ha?"). |
Im dritten Teil lesen Sie, wie das Projektteam bei Laune gehalten
wird. |
Kommentare zu diesem Artikel:
|
