Bewerberblog.de

Die ganzen Informatikberufe sind auch kein Ponyhof. Und wer behauptet denn das BWL “nichts richtig gelerntes” sein soll? Ich höre das zum ersten Mal. Mir fehlt ein sehr wichtiges Vorurteil in dem Text: Viele glauben das Informatiker automatisch alles wissen und können was mit Computer zu tun hat. Der berühmte Satz “Sie arbeiten/machen doch mit Computer. Könnten Sie mal…” ist sehr nervig. Das ist so als würde man zu einem Maurer sagen “Sie sind doch Handwerker…” und fragt ihn Dinge über Möbelrestaurierung oder andere Holzarbeiten. Jeder IT-Beruf ist anders mit einer anderen Ausbildung.
Außerdem gibt es das Vorurteil wo die Leute glauben alles würde sehr schnell gehen. Viele haben keine Vorstellung davon wie lange man bei manchen Projekten sitzen muß, bis diese fertig sind. Monster gab z.B. 6 Monate als Zeitraum für die Überarbeitung und des Relaunchs an.

@Strangerli: Ja, diese Erwartungshaltung, man könne alles im IT-Bereich, nur weil man Informatik studiert hat, kenne ich auch aus der BWL. Nur weil man BWL studiert hat, kann man deswegen noch keine Lohnsteuererklärung machen, die alle Tricks und Kniffe schon beinhaltet. Der Zugang zu diesem Wissen ist vielleicht leichter, aber es gibt Gründe, warum man sich im Studium spezialisieren kann und sollte.

@Martin: Die Sache mit dem Missmanagement ist, glaube ich, ein großes Problem, warum es solche Vorurteile gibt. Viele Techniker, ITler und Naturwissenschaftler glauben aber, dass es einfacher ist, ein bisschen Projektmanagement zu lernen als andersherum: Wenn der BWLer die Technik verstehen muss. Aber wie oft erlebt man es denn, dass sich die Techies zu lange und zu kleinteilig in ein Projekt verrennen und das große Ganze aus den Augen verlieren? Ich denke, das wichtigste ist einfach, die Kommunikation zwischen beiden Seiten. Das gilt im Übrigen auch zwischen Auftraggeber und Auftragnehmer.

Ich glaube das eigtl. Problem ist, dass BWLer gern in Leitungspositionen eingesetzt werden ohne den technischen Bereich durchlaufen zu haben. Sie haben nicht einfach “keine Ahnung”, sondern sie haben keine Produktvision. Ohne Produktvision ist man aber für solche Führungspositionen ungeeignet. Es reicht als Vision einfach nicht, die Aktionäre mit guten Zahlen beglücken zu wollen oder bestimmte Renditeziele zu erreichen. In der Folge denken diese Leute häufig zu kurzfristig und das fällt in den unteren Etagen - nicht nur bei der IT - auf. Das Ergebnis ist Mißmanagment, in Form des “Management by Champignon”. Dies führt dazu das die Ziele eben nicht erreicht und erfahrene Mitarbeiter systematisch frustriert werden. Die Folgen dürfen die unteren Etagen in Form von Lohnkürzungen oder Entlassungen ausbaden.

Das nächste Problem ist, dass einige BWLer denken sie seien zum Anforderungsanalysten berufen, nur weil sie das Wort “Pflichtenheft” buchstabieren können. Dabei vergessen sie, dass es einen Grund gibt warum dies ein eigener Berufszweig innerhalb der Informatik und eben nicht der BWL ist. Es gibt eben einen guten Grund, weshalb ein Software Engineer 2 Jahre lang Vertiefung in Analyse und Design von Softwareprojekten an der Uni hat.

Verständlicherweise sträuben sich die Anforderungsgeber dann heftig gegen den Teil agiler Entwicklungsmethoden, welcher die Leistungen des Anforderungsgebers transparent macht und verlangt, dass ein “Pflichtenheft” eben keine gottgegebene Sache, sondern bestenfalls Verhandlungsbasis ist und selbstverständlich vom Anforderungsgeber (nicht vom Entwickler) ständig gepflegt und aktualisiert werden muss. Insbesondere müssen auch technische Anforderungen und Constraints, sowie die gern vergessene Zuordnung von Zugriffsrechten dokumentiert werden. Viele Pflichtenheftschreiberlinge sind aber der Meinung, eben solche Dinge hätten sie nicht nötig - die IT-Abteilung solle mal “selbst denken”. Abgeliefert werden dann (falls es überhaupt schriftliche Anforderungen gibt) zum Teil seitenweise 1:1 aus völlig artfremden Projekten kopierte Generalfloskeln und tonnenweise schlecht oder gar nicht dokumentierte Excelorgien.

Die Folgen sind absehbar: Projekte liefern nicht was der Kunde wollte, kommen zu spät, kosten zu viel Geld, Überstunden, Frustration. Und wer ist hinterher der Schuldige? Nein: nicht der BWLer der falsche und unvollständige Anforderungen weitergeleitet hat, sondern der Informatiker der das Projekt umgesetzt hat. Denn der Informatiker hätte “nicht verstanden worum es geht”. Nun: wir hätten sie gern verstanden, aber die feinen Herren reden doch nicht mit uns! Geschäftsleitung redet nur mit Geschäftsleitung, Management redet nur mit Management und der IT-Projektleiter darf hinterher demütig anhören, was “Gott” gesprochen hat. Grandios!

So ziemlich jeder Informatiker hat das in seinem Leben mindestens 1x von A-Z durch. Ich glaube genau deswegen sind solche Leute für die meisten ITler ein rotes Tuch. Weil die Schnittstelle zwischen BWL und Informatik unbesetzt bleibt und die BWLer nicht mit den ITlern reden (wollen). Viele sind der Ansicht, sie hätten das nicht nötig.

Im Übrigen bin ich aber der Meinung, die ITler sollten versuchen sich ihren BWLer ordentlich zu “erziehen”. Die Anforderungen sind das “Produkt” des Anforderungsgebers. Fehlerhafte Anforderungen sollten deshalb solange zurückgewiesen werden und das Projekt nicht starten, bis die Anforderungen eine akzeptable Qualität haben.

Danach sollte über die Anforderungen verhandelt werden im Sinne des: “Du kannst dieses Feature haben wie du es beschrieben hast, aber das kostet dich 2 Wochen extra. Wenn du hingegen auf diesen Teil verzichtest und wir es ein wenig anders umsetzen, kostet es nur 2 Tage.”

Dank SCRUM können wir solche Dinge machen: sofern die Geschäftsleitung mitspielt. Im Endeffekt hilft dies allen Beteiligten. Voraussetzung bleibt, dass der Anforderungsgeber nicht wieder mit dem Totschlagsargument kommt: “ich bin zu wichtig dafür und habe keine Zeit”.

Uiuiui, hier prallen ja wieder Welten aufeinander, habe ich das Gefühl
Ich stimme jedenfalls Daniela voll und ganz zu, dass die Kommunikation zwischen den Teammitgliedern und Auftraggebern/Auftragnehmern funktionieren muss. Das Hineinversetzen in den anderen ist oft der Schlüssel: *Warum* stellt der BWLer absurde Anforderungen (weil er wiederum den Druck von weiter oben/von der Wirtschaft kriegt; weil er nicht allwissend ist und deshalb die Schritte nicht nachvollziehen kann, die nötig sind;…)? *Warum* verschiebt sich dieses Feature und damit womöglich das gesamte Projekt (weil es einen in letzter Minute entdeckten fetten Bug gab und der neue Code erst ausführlich getestet werden muss; weil Informatiker nicht zaubern können; weil es ein Sicherheitsloch im adaptierten Code gibt;…)? Sich das gegenseitig offen zu erklären braucht Zeit, oft einen großen Sprung über seinen Schatten und manchmal einen neutralen Dritten.
Das lässt sich imho übrigens auf so gut wie alle interdisziplinär bearbeiteten Projekte übertragen.

Ein IT-Arbeitsplatz mit einer Arbeitszeit von 9 bis 5? Wenn sich das in den Branchen überall ändert warten rosige Zeiten auf ITler. Nie wieder kurz vor Feierabend eine “wichtige” und “dringende” Aufgabe erledigen zu müssen wäre eine Zukunft, bei denen auch die “Nicht-Normalo-Informatiker” mal die Zeit haben Abends auszugehen.

Jetzt beginnen wir von Normalos und Nicht-Normalos zu sprechen (Was ist normal?), Subkategorien der Informatik, IT-Führungskräfte, deren Vor- und Nachteile sowie das Peter-Prinzip. Aber dann würden wir die BWL-Menschen, auf den der Klischee-Vergleich des Blogs zielt, ausschließen.

@Marcus: Das hängt sicher von der Betrachtungsweise ab. Nehmen wir mal an, der BWLer ist Projektleiter, der Orga- und Management-Aufgaben übernimmt, alles kontrolliert und delegiert. Aus Sicht der anderen Projektteilnehmer, die alle spezielle Aufgaben in dem Projekt übernehmen, ist der BWLer sicher der Generalist. Aus einem anderen Blickwinkel kann man aber auch sagen, dass der BWLer ein Spezialist auf dem Gebiet des Projektmanagements ist.