zkmlf: Dokumentiert! Besonders, wenn es stressig ist
Wenn irgendwas unerwartet schief läuft (und das wird es - niemand kann für alle Eventualitäten planen), schreibt Euch auf, was wann wie nicht funktioniert hat, notiert, welche Tests Ihr durchgeführt habt und woran es schließlich lag. Daraus könnt Ihr nur lernen, und im Zweifel hilft Euch diese Dokumentation, um in der Nachlese zu erklären, was da eigentlich passiert ist. Wer schreibt, der bleibt - dieser Spruch ist nie so wahr wie in Streitigkeiten mit dem Kunden. Ich habe gute Erfahrungen damit gemacht, ein Diktiergerät neben mir liegen zu haben, denn ein kurzer Zwischenstand lässt sich schneller sprechen als schreiben, und nebenbei hat es auch noch den Vorteil, dass der Kunde einem nicht über die Schulter guckt und in dem Text, den man eben nur so als Gedächtnisstütze hingeschludert hat, anfängt herumzukorrigieren. Zeit, um das diktierte zu schreiben und in druckreife Form zu gießen, habt Ihr außerhalb der heißen Migrationsphase noch genug. Im Nachhinein geschriebene Braindumps sind oft zu lückenhaft und manchmal auch schlicht inkorrekt.
Natürlich solltet Ihr auch dokumentieren, wenn Ihr nicht an einer Verzögerung schuld seid. Mit vom Kunden verursachten Verzögerungen (Rackschlüssel nicht da, Suche nach Montagematerial, Patchkabeln etc) kommt man einem wutschnaubendem Manager prima bei, der die Begründung dafür haben möchte, warum man am Ende der angekündigten Downtime immer noch nicht wieder vollständig "up" ist. Im Idealfall wäre man ohne die vom Kunden zu verantwortende Verzögerung gerade "in time" fertig geworden, oder, noch besser, die Bräsigkeit des Kunden hat die eigene Arbeit so verzögert, dass man selbst noch unverschuldet weitere Verzögerungen erzeugt hat.
Comments
Display comments as Linear | Threaded