SEO- und Internet-News by TechDivision


Outsourcing und Near-Shoring in der Software-Entwicklung

Gepostet in Entwicklung/Programmierung durch Marion Engel am 28 April, 2008

Es war einmal ein Software-Haus, in dem die Geschäftsleitung den Mitarbeiternvor einigen Jahren mitgeteilt hat, dass in Zukunft auf Entwickler in einem Ostblock-Land zurückgegriffen würde. Zunächst hatten natürlich alle Angst, dass in diesem Zuge zumindest einige Arbeitsplätze in Deutschland wegfallen würden. Nein, so die Geschäftsleitung, das Gegenteil sei der Fall. Durch das Outsourcing würden die deutschen Arbeitsplätze gesichert. Durch die Preisvorteile, die sich durch die Kollegen im Ostblock ergeben, könne man ganz andere Projekte „an Land ziehen“. Und überhaupt, würden die Kunden ganz einfach verlangen, dass Outsourcing im Angebot enthalten ist.
Wenn es der Kunde verlangt, darf der „kleine“ Mitarbeiter natürlich nicht widersprechen. Ob die Rechnung letztendlich aufgegangen ist, wurde allerdings nie verraten. Für die Mitarbeiter war nur ersichtlich, dass die ausländigen Kollegen schon bald nach höherem als nur simplen Programmiertätigkeiten verlangt haben, dass es durch die geografisch verteilte Arbeit noch mehr „Häuptlinge“ gab, dass simple Team-Meetings per Video-Konferenz ausgetragen werden mussten und dass man bei Fragen nicht mal schnell zum Kollegen ins Nachbarzimmer gehen konnte.

Der Kunde verlangt es – aber was genau verlangt er denn? Wenig zahlen will er, das ist ziemlich klar. Das wird uns ja ständig von der Werbung suggeriert. Ob nun Geiz geil ist, die Preise unter der Tiefpreislatte bleiben müssen oder irgendwas fast nixx kost’. Inzwischen steuert die Werbung allerdings auch schon gegen und will dem Konsumenten klar machen, dass ein Schnäppchen ja unter dem Strich eigentlich viel mehr Aufwand verursacht als man meint. Aber ein Kunde, der eine Software-Anwendung benötigt, hat mit Sicherheit auch genaue Vorstellungen, was diese Anwendung können muss. Und er hat sicher ebenso hochgesteckte Erwartungen an seinen Dienstleister. So möchte er, dass

  • der Zeitplan eingehalten wird
  • die Anwendung stabil und möglichst fehlerfrei ist
  • er einen Ansprechpartner, der Fragen schnell und in der gleichen Sprache beantworten kann
  • die Anwendung später schnell und problemlos erweitert werden kann

Es ist allerdings nicht so, dass die Aufgaben, die in einem Software-Projekt anfallen, in isolierte Arbeitspakete geteilt, an unabhängig arbeitende Programmierer verteilt und nachher einfach zusammengeführt werden können. Auch wenn eine Software-Anwendung eine Einheit aus mehreren Teilen ist, müssen diese reibungslos zusammenarbeiten. Baut ein Programmier ein Puzzleteil mit einer runden Aussparung, der andere allerdings ein Puzzleteil mit einem eckigen Ärmchen, kann kein Bild entstehen, auch wenn die einzelnen Puzzleteile noch so schön sein sollten.

Nun mag man einwenden, dass die Anforderungen ja eindeutig in der Spezifikation festgelegt sind. Richtig, aber bei einer internationalen Zusammenarbeit kommen unterschiedliche Sprachen ins Spiel. Mindestens einer der Beteiligten wird eine Spezifikation vorfinden, die nicht in seiner Muttersprache vorliegt. Mindestens einer der Beteiligten wird die Kommunikation in einer Sprache durchführen müssen, die nicht seine Muttersprache ist. Im „schlimmsten“ Fall gilt für die Spezifikation und Kommunikation eine Sprache, die für keinen der Beteiligten die Muttersprache ist. Nicht nur, dass hier die Wahrscheinlichkeit für Missverständnisse und vermehrte Nachfragen steigt, es sind auch immer wieder Übersetzungsarbeiten erforderlich. Wie lange dauert es, eine Dokument von 100 Seiten gut und fehlerfrei zu übersetzen? Was kostet diese Arbeit, wenn sie intern durchgeführt wird, was, wenn sie extern vergeben werden muss? Was kostet die sprachbedingt zusätzlich erforderliche klärende Kommunikation an Zeit und Aufwand? Und was ist, wenn der Programmierer etwas anderes baut, als verlangt war, weil er es falsch verstanden hat? Dass hierdurch Verzögerungen im Zeitplan auftreten und das interne Budget in eine Schieflage geraten muss, sollte klar sein.

Was ist, wenn der Programmierer, der an einer isolierten Aufgabe ohne Gesamtblick auf das Projekt und ein gewisses „Feeling“ für den Kunden arbeitet, Variablen mit wenig sprechenden Namen bezeichnet oder mit der Zeit frustriert ist und bei der Dokumentation des Codes nachlässig wird? Wenn nach einigen Monaten Änderungen oder Erweiterungen seines Codes erforderlich sind, ist er – nach Murphy – meist nicht mehr verfügbar oder kann sich selbst nicht mehr erinnert, was er damals zusammenprogrammiert hat. Also gerät erneut der Zeitplan in Gefahr, da sich ein anderer Programmierer erst einarbeiten und den Code verstehen muss.

Das sind nur ein paar Überlegungen, mit denen ich nicht sagen will, dass Outsourcing nicht funktionieren kann. Ich möchte nur davor warnen, Outsourcing als das Allheilmittel für alle Lebenslagen zu betrachten. Wirtschaftlich denken ist zwar in Ordnung, aber bevor man übertriebenes Sparen und Drücken von Preisen beginnt, sollte man nachdenken, ob dies wirklich nötig und angemessen ist. So gab es vor kurzem ein positives Beispiel von Solidarität im Preiskampf: Die Österreichischen Bundesforste haben zwei Sägewerke von ihrer Kundenliste gestrichen, die kleinen Waldbauern das Holz nach dem Sturm Paula um bis zu 30 EUR unter dem Marktpreis abgekauft hatten.

Wer Erfahrungen mit dem Outsourcing in Software-Projekten hat, ist eingeladen, diese in einem Kommentar mit allen zu teilen.

Abonnieren Sie jetzt unseren RSS-Feed und bleiben Sie so immer auf dem Laufenden!


Diese Artikel dürften Sie auch interessieren


2 Antworten zu 'Outsourcing und Near-Shoring in der Software-Entwicklung'

Kommentare verfolgen mit RSS oder einen TrackBack setzen zu 'Outsourcing und Near-Shoring in der Software-Entwicklung'.

  1. Dax-Mitarbeiter (1 comments) kommentiert

    am 30 April, 2008 um 21:54

    In einem DAX-Konzern für den ich gearbeitet habe wurde auch immer mehr outgesourct. Allerdings hatte man auch schnell gemerkt, dass dadurch kein Geld gespart werden kann. Aufträge gehen zwar immer noch nach Indien, aber eher weil hierzulande Ingenieure fehlen, und nicht weil die Entwicklung dort billiger ist.

  2. Gustav (1 comments) kommentiert

    am 1 May, 2008 um 23:18

    Schöner Artikel!

Einen Kommentar abgeben



Comments links could be nofollow free.