Gerade in der IT hat man manchmal das Gefühl, dass manche um des Rudern willen rudern. Der Trick ist eben genau nicht zu rudern, sondern sich eben auch um sowas wie Prozesse wirklich zu kümmern. Oder besser gesagt: An der richtigen Stelle zu rudern. Und nicht von einem Krisenmanagement-Schlammloch zum nächsten zu hopsen (meine Arbeit ist und war oft so).
Wenn man als Entwickler sagt, dass das sowieso alles Quark ist, dann ist es völlig logisch, dass dieses Thema irgendwann die Power Point Profis übernehmen, die aber Dinge oft nicht verbessern.
Sich darum zu kümmern die Prozesse von einem selber und der Gruppe in der man arbeitet zu verbessern, ist verdammt anstrengend und oft frustrierend. Wenn mans ehrlich macht sieht man nämlich, wie viel Effizienzfehler man selber macht.
Die Heroe Zeit dieser Branche ist definitiv Geschichte.
Wenn du nämlich Managern irgendwann mit betriebswirtschaftlichen Ideen kommst, dann wird man oft am ersten Tag nicht ernstgenommen (Gewohnheit). Am nächsten Tag kommt der dann aber. Und dann merkst du erst, wie in der IT gedacht wird.
Wir haben 4 bis 6 wöchige Updates an mehrere Kunden. Natürlich brauchen die Kunden dann eine Feature Liste von dem neuen Zeugs. Natürlich gucken die sich nicht die ganze Doku durch was es Neues gibt. Das scheitert dann aber z.B. an so Dingen, dass dir einer erklärt, dass das System für Kundenmails kein RichText kann.
Wenn man dann nicht sofort um ein Meeting bittet, wäre die Idee gestorben.
Ich kann mir vorstellen, dass Manager unter solchen Bedingungen sehr schnell frustrieren. Das Chaoten-Image der Entwickler kommt eben nur teilweise von der Komplexität ihres Jobs, den viele nicht begreifen.
Oder: Wenn ich jetzt einen Swing Client für mein Webservices Beispiel progge, dann kann ich mich auch einfach hinsetzen, ein Lachen aufsetzen und sagen: Es ist alles nur Code. Ich hätte in 2 Stunden etwas fertig. Das sähe Scheisse aus und hätte ein paar lustige Bugs. Aber egal. Ich hätte gerudert. Ich kann mir aber auch das (gekaufte) PDF vom serious intelectual für Swing Scott Delap nehmen und versuchen seine Ideen zu integrieren, dass die Oberfläche gut aussieht und keine Bugs hat. Das dauert natürlich beim ersten mal länger und es ist auch nicht so super spannend sich source code von anderen Leuten anzuschauen.
Axel