Meine Arbeitsweise
In der IT machen alle dasselbe. Denken Sie vielleicht. Aber so wirklich richtig ist das nicht. Jeder IT-Dienstleister unterscheidet sich in seiner Arbeitsweise. Das ist auch der Grund, warum in der IT so viel diskutiert wird: There is more than one way to do it. Die Arbeit in der IT muss deswegen noch viel mehr als in anderen Bereichen von Kompromiss und Konsens geprägt sein.
Deswegen ist es auch so wichtig, dass man in der IT trotz allen Nerdtums neben der eigentlichen Arbeit mit Bits, Bytes, Datenformaten und Protokollen vor allen Dingen miteinander redet.
Generalist? Spezialist? Fachidiot?
Ich habe mein Wissen als Schwerpunkt in der Breite organisiert. Durch langjährige Erfahrung in den verschiedensten Bereichen kann ich mich schnell in neue Arbeitsgebiete einarbeiten, behalte den Überblick und sehe die Dinge in Ihrem Zusammenhang. Ich möchte mich trotzdem ungern als Generalist bezeichnen, denn erstens bin ich trotz aller Breite meines Wissens IT-Spezialist, und zweitens gibt es durchaus Fachgebiete, in denen ich mich auch in der Tiefe detailliert auskenne. Sie werden beim persönlichen Kennenlernen bemerken, dass das gar nicht so wenige Fachgebiete sind. Auch in den Bereichen, in denen ich mich nicht als Spezialist aufgestellt habe, bin ich nach kurzer Einarbeitungszeit in der Lage, mit den Fachleuten dieser Gebiete auf Augenhöhe zu kommunizieren und zusammenzuarbeiten.
Diese Struktur meines Fachwissens prädestiniert mich für Aufgaben in Querschnittsbereichen wie Architektur und Infrastruktur, wo es auf die Zusammenarbeit mit zahlreichen anderen Fachgebieten ankommt.
Besonders gut kann ich mein IT-Talent einsetzen, wenn ich neben meinem “eigentlichen” Auftrag dort zum Einsatz komme, wo es gerade technisch oder menschlich hakelt und vielleicht zwei Systeme oder zwei Teams, die miteinander kommunizieren und kooperieren müssen, nicht so ineinander greifen wie sie es sollten.
Lösung technischer Probleme
Im technischen Fall trete ich gerne ein, zwei Schritte vom konkreten Problem zurück und schaue mir auf den unteren Ebenen an, was auf den Systemen und den beteiligten Kommunikationswegen eigentlich passiert. Dabei setze ich weit unten angreifende Tools wie wireshark, tcpdump, strace und ltrace ein, um eine vielleicht von den Applikationsspezialisten oder dem Bauchgefühl aufgestellte Arbeitshypothese zu belegen oder als falsch zu identifizieren. Auf diese Weise kommt man üblicherweise sehr schnell zu Ergebnissen - auch wenn es nur der Hinweis ist, auf welcher Seite der Kommunikationsbeziehung man weiter nach dem Fehler suchen sollte. Nicht selten ist es auch der Fall, dass man sich eine sprechende und zielführende Fehlermeldung buchstäblich von der Leitung oder aus einem verstecken Log “kratzen” kann, während die Applikation dem Benutzer gegenüber nur einen “Internal unspecified EError” meldet.
Lösung menschlicher Probleme
Im menschlichen Fall benutze ich meine durch die jahrelange Mitarbeit in einer Anwaltskanzlei geschärften Kommunikationstalente, um - ggf. im Einzel- oder Gruppengespräch - herauszufinden, wo genau es hakt, wer nicht mit wem reden kann, wer vielleicht Dinge verschweigt oder kreativ auslegt und wie man die Kommunikation wieder zielführend in Gang bringen kann. Sehr oft ist es ausdrücklich hilfreich, jemand “von außen” zu sein, der außerhalb von Hackordnung und politischer Konflikte steht und neutral an die Dinge herangehen kann.
In der Kombination des technischen und menschlichen Knowhows sind Problemlösungen dann nicht mehr weit.
Man muss nicht alles wissen. Aber man muss wissen wo man es findet.
Aber auch alleine kann ich mein Wissen zielführend und nachhaltig für Ihre IT-Systeme einsetzen. Ich bin ein guter Rechercheur, bewege mich flüssig auch in “exotischen” Internetmedien und kann dort technisch fundierte, gut begründete und ausformulierte Fragen stellen, die in aller Regel - vielleicht nach einiger Diskussion - dann Antworten bekommen und für die Ausarbeitung von Lösungen hilfreich ist.
Schließlich ist das seltsame Verhalten von Software schnell erklärt, wenn man kurz mit dem Entwickler gesprochen hat und sich mit diesem geeinigt hat, ob und warum das Verhalten so gewollt ist oder ob es sich vielleicht gar um einen Bug handelt.
Nach Lehrbuch? Das ist nicht unbedingt das richtige.
Die Fallbeispiele aus Herstellerdokumentation haben oftmals mit der Praxis nicht viel zu tun. Gerne sind sie für die Realität untauglich vereinfacht, die bei der realen Anwendung bestehenden Hürden in der Doku klar umschifft, oder sie decken im anderen Extrem einen exotischen Spezialfall aus dem Leben des Entwicklers detailliert ab, während die einfachen oder anders komplex gelagerten Aufgaben unerwähnt blieben.
Da ist dann der Experte gefragt, der mit Erfahrung, Fantasie und Intuition an die Aufgabe herangeht, das geeignete Tool für die Aufgabe aussucht und dieses dann der Aufgabe gerecht aufbaut. Ich mache offen gestanden selten Dinge so wie sie im Lehrbuch stehen, und manchmal fühlt sich die von mir vorgeschlagene Lösung wie ein Verbiegen des Werkzeugs an, aber wenn am Ende das Ziel “in time” und für weniger Budget als zunächst vermutet erreicht ist, ist allen geholfen. Andererseits ist natürlich klar, dass eine Lösung einfacher an andere Leute zu übergeben ist, wenn sie so aufgebaut ist, wie es derjenige, der das Tool bereits aus einer anderen Welt kennt, erwarten würde. Den richtigen Kompromiss aus “der Aufgabe angemessen” und dem “Principle of least surprise” zu finden, ist eine meiner Stärken.