Wie arbeiten Firmen mit externen Programmierern (Indien) zusammenzuarbeiten?

[Unfug]

Hallo 3dc,

letzte Woche habe ich eine interessante Erfahrung gemacht. Konkret ging es um folgendes:

Meine Firma arbeitet mit einer anderen großen Softwarefirma zusammen. Aufgrund eines Problems, welches tief im System war, war es nun so, dass die Softwarefirma sagte wir machen ein Desktopsharing+Telefonkonferenz mit dem zuständigen indischen Programmierer.

Was mich jetzt wunderte war: Der Inder hatte absolut keine Ahnung von der Software der Firma. Der hat die ganze Zeit nur eine Lib programmiert, aber wusste nicht wozu die genutzt wird.
Wir haben ihn dann erstmal erklärt, was die Software macht und wo seine Lib eingesetzt wird.

Mich hat es gewundert, dass das so einfach funktioniert (bis zum Fehler). Der Programmierer wusste nicht einmal wo und wie seine Lib eingebunden wurde. Meine Frage ist: Wie geht man bei solch einer Aufgabenverteilung vor?

Vor allendingen wie können die Inder das testen? Eine Lib zu schreiben ist nicht schwer, aber dass diese dann richtig funktioniert im gesamten System?

Die Sache ist, es war eine sehr spezifische Lib und nicht eine wie bei den OpenSource Libs, die man so im Internet kriegt.

Mich würde eure Erfahrung mal interessieren und wie ihr das handhabt.

Danke

[PatkIllA]

Schnittstellen spezifizieren und das wars doch im wesentlichen.
Was ist denn daran so verwunderlich?
Bei einer halbwegs brauchbaren Archtitektur ist die Schnittstelle nach außen auch relativ überschaubar.
Ich kenne jetzt eure Umgebung nicht aber da werdet ihr auch hunderte Komponenten benutzen, die der Ersteller nie so getestet hat.

[Shink]

Naja, wenn ihr genau spezifiziert, wie sich die Lib unter welchen Umständen verhalten soll, könnt ihr natürlich auch automatische Abnahmetests programmieren. Oder programmieren lassen. Am besten dann in Kasachstan.

Blöderweise ist dann halt sichergestellt, dass niemand mitdenkt. Das Verhalten in Fällen, die nicht spezifiziert sind, ist vielleicht/wahrscheinlich unerwünscht.

[Monger]

Wir haben in unserer Firma auch einen größeren Teil der Entwicklung nach Indien outgesourced. Ist rein organisatorisch zwar immer noch die selbe Firma, aber die Probleme sind ähnlich.

Wir haben da sehr wechselhafte Erfahrungen gemacht. In einigen Bereichen läufts ganz gut, mit anderen wiederum überhaupt nicht. Kommt wohl auch drauf an, ob die nur Zulieferer sind, oder eigene Projektverantwortung haben. Bei ersterem wird oftmals nur genau das gemacht was gefordert ist, letzteres scheint mir deutlich besser zu funktionieren.

Was die Lib angeht: gutes Library Design ist eine Kunst. Wenn die API gut designt wurde, ist die Lib mehr als nur die Summe aller Teile. Es hilft, wenn man ein paar Anwendungsbeispiele im Hinterkopf hat, aber man muss nicht alle kennen.
Wenn bisher in der Library keine Fehler aufgefallen sind, kann das entweder bedeuten dass die Inder ziemlich sorgsam gearbeitet haben - oder dass nur ein Bruchteil der Library genutzt wird. "Bisher hats ja funktioniert" ist kein Qualitätsmerkmal.

[Tommes]

Wäre es nicht ein guter Ansatz, zusammen mit der Schnittstellen/Lib Spezifikation auch gleich Unit-Tests zu liefern, welche die Lib erfüllen muss?

[Monger]

Wäre es nicht ein guter Ansatz, zusammen mit der Schnittstellen/Lib Spezifikation auch gleich Unit-Tests zu liefern, welche die Lib erfüllen muss?
Wenn man bei einer Lib die gesamte offene API spezifiziert (am besten noch inklusive Doku) und auch noch die Tests dazu liefert, dann kann man es auch gleich selbst machen. Das ist wie dem Hasen Pfeffer auf den Schwanz streuen.

[Shink]

Wäre es nicht ein guter Ansatz, zusammen mit der Schnittstellen/Lib Spezifikation auch gleich Unit-Tests zu liefern, welche die Lib erfüllen muss?
Schrub ich ja.

Allerdings könnte man dann die Frage stellen: Wenn ich die Unit Tests selbst programmieren kann und mir alle möglichen Testfälle einfallen, lohnt sich Outsourcing für den Rest überhaupt noch?

Prinzipiell kann ich dann nämlich einen Zufallsgenerator so lange Code erzeugen lassen, bis meine Tests durchlaufen.:freak:
(Von nichtfunktionalen Anforderungen hat ja auch noch niemand etwas erwähnt.)

[Gast]

Eine Lib zu schreiben ist nicht schwer, ...

Das ist schonmal eine sehr naive Annahme, bei der auch immer ein wenig Überheblichkeit mitschwingt und zwar bei denen die glauben, dass der "Programmierfuzzie" das mal eben so macht. An solchen Äußerungen hat man sich ja schon beinahe gewöhnt ...

[Tommes]

Wenn man bei einer Lib die gesamte offene API spezifiziert (am besten noch inklusive Doku) und auch noch die Tests dazu liefert, dann kann man es auch gleich selbst machen. Das ist wie dem Hasen Pfeffer auf den Schwanz streuen.

Okay das ging dann vielleicht einen Schritt zu weit, aber wie wäre es mit User Stories oder Use Cases? Vielleicht etwas ungewöhnlich für ein Api, aber damit könnte man imho ganz gut umschreiben, wie man die Api später nutzen möchte, was man erwartet, was Fehlersituationen sein können und wie damit umgegangen werden soll.

Auf dieser Basis könnte dann implementiert werden und eine gute Grundlage für realistische Unit Tests wären auch gegeben.

[Monger]

Okay das ging dann vielleicht einen Schritt zu weit, aber wie wäre es mit User Stories oder Use Cases?
Ich glaube, dass es selten ist dass ein externer Kunde ankommt und konkret vorlegt: "ich möchte gerne diese Lib haben, die genau dieses und jenes kann"
Ich glaube, häufiger ist dass aus dem Feld so eine ganz grobe Vorgabe kommt ("wir würden gerne alle unsere Outlook Mails in einem bestimmten Format speichern, ohne über die Oberfläche gehen zu müssen"), und von den eigenen Entwicklern dann konkret wie eine gescheite API aussehen könnte.

Wie gesagt: das ist mehr Kunst als Wissenschaft. Du gehst ja auch nicht zu van Gogh hin, und sagst: "Ich hätte gerne ein Bild von einer Windmühle, in einem pointillistischen Stil, und der Himmel soll eine lila Farbe haben um mit dem grünlich-blauen Ton des Grases zu harmonieren"
Meistens willst du einfach nur ein schönes Bild, ohne selbst wirklich zu verstehen warum du dieses oder jenes schön findest.

Der moderne Ansatz (zumindest was unser Guru für agile Entwicklung sagen würde): man schaut dass man den Kunden zur Entwicklungszeit mit an den Tisch bekommt. Man darf das nicht überstrapazieren, und man darf sich auch von dem Kunden nicht umherschubsen lassen, aber wohin genau eine komplexe Software strebt, sieht man meistens erst wenn man dran arbeitet. Da hilft natürlich alles, was irgendwie als Denkstütze funktioniert: User Stories, Diagramme, Pseudocode etc. -.

Unser Guru würde auch sagen: Modultests lassen sich vom Produktivcode nicht trennen. Die gehören völlig selbstverständlich zum Handwerkszeug eines Entwicklers, so wie Code Konventionen und Dokumentation. Der Entwickler muss nachweisen dass er hochqualitativen Code geschrieben hat, nicht der Kunde.
Um sicherzustellen dass nicht nur irgendwas hochqualitativ entwickelt wird, sondern wirklich das was der Kunde später braucht, bieten sich Integrationstests an. Das ist dann wiederum Aufgabe der QA (so denn eine existiert), die ja nach innen hin die Interessen der Kunden vertritt.

[PHuV]

@Threadtitel

Deswegen kann man die meiste Software aus dem Ausland auch nicht richtig nutzen oder muß wieder neu geschrieben werden. Das ist ein trauriger Fakt.

Wie manche schon bemerkt hier richtig bemerkt hatten, ist die Theorie von Softwaredesign und Schnittstellen an sich eine hohe Kunst, welche durchaus realisierbar ist, so daß dann Menschen nicht alles wissen müssen, um eine entsprechende Schnittstelle zu versorgen. Jedoch zeigt sich immer wieder, daß es immer besser ist, wenn die Leute wissen, warum, wieso, weshalb und wo ihre SW laufen wird. Je besser die Information, je besser der Austausch zwischen den Teams ist, umso besser wird dann auch das Endprodukt, die Software.

Es wird immer vergessen, daß jede Einheit für sich betriebsblind ist, auch diejenige, die das Design und die Schnittstellen spezifizieren. So kann man oft viele Dinge wie Prozesse, Kommunikation usw. verbessern und vereinfachen, wenn die Teams mit ihrem Know-How zusammenarbeiten, weil jeder mit seinem Wissen beitragen kann. Sehr oft habe ich erlebt, wie das Rad (oder Räder) sprichwörtlich in vielen Modulen mehrfach immer wieder neu erfunden wurde. Und jeder, der ernsthaft mal in größeren Teams oder in größeren Projekten programmiert hat, weiß das so was immer wieder passiert. Und die Räder haben eben oft verschiedene Implementationsansätze, die entsprechend in bestimmten Umgebungen ihre Stärken ausspielen, und bei anderen kläglich versagen.

Dagegen hilft nur eines, Informationsaustausch und gut gesteuerten Kommunkationsfluß und Informationsverbreitung. Klar nerven die permanenten Sitzungen, Reviews, Milestone-Meetings usw. Aber sie sind das leider einzig effiziente Mittel gegen die genannten Dinge. Und genau deshalb funktioniert eben meistens Programmierung mit verschiedenen Nation und deren verschiedenen Denkweisen eben nicht. Man unterschätzt einfach den Einfluß von Kultur und Herkunft, auch wenn die Informatik an sich neutral sein soll. Sie ist es aber eben nicht, weil Menschen dahinterstecken. Und die Kommunikation funktioniert ja oft nicht mal innerhalb einer Kultur oder Firma richtig:

http://tamingdata.com/wp-content/uploads/2010/07/tree-swing-project-management-large.png

Deshalb bin ich heute davon überzeugt, daß man gute SW nur dann schafft, wenn jedes Glied ungefähr weiß, was und wofür es etwas programmiert. Erst wenn der Gesamtsinn vorhanden ist, und der große Zusammenhang ungefähr erfaßt wird, kann daraus etwas werden. Da kann man dann eben nicht so einfach jemanden hinsetzen und sagen: "Mach mal." Das geht meistens in die Hose, wie man tagtäglich in diversen Projekten erleben kann.

[Gast]

Ich bin kein Programmierer, muss aber PHuV zustimmen.

@ T.E.
Generell erfordert Outsourcing jeglicher Art erhebliche Mehraufwände in Form von Blueprints und Kontrolle damit das überhaupt irgendwie funktioniert (m.E. mal gut 20%+). D.h. für 8 outgesourcte Programmierer-Stunden brauche ich inhouse noch jemanden der mindestens 1,5 Stunden erklärt und kontrolliert. Wenn ich das nicht will dann muss ich, wie hier im Thread schon erwähnt, auch die Verantwortung für das Projekt oder Teilprojekt rausgeben - verliere aber Kontrolle und erhöhe die Kosten (etwa um den gleichen Teil den ich intern spare).

Komplettes Outsourcing macht auf lange Sicht oftmals keinen Sinn, kostet genauso viel und ich mache mich abhängig vom Zulieferer / Outsourcer. Für einmalige Sachen oder kurze Zeiträume ist es OK.
Die generelle Einstellung des "Managements" oftmals der BWL Stundenten (sorry ;-)) kann man ziemlich gut an unsereren vielen wachsenden Mittelständlern beobachten...

Es gibt fast keine mehr.

[Gast]

Um mal meine Erfahrung zu berichten.
Ich habe selbst Kollegen aus Indien (aber auch aus Weißrussland, China) ausgebildet (Dort in Bangalore und hier in Deutschland) mit einem sehr gemischtem Ergebnis. Zeitweise waren die Eindrücke und Leistungen sehr gut und dann war es manchmal kurz vor der Eskalation. Es ging und geht um sehr "lebenskritische" Sachen, welche wir hier nicht mehr stemmen konnten.
Ich werde hier mal keine Details erwähnen, aber die Software wird weltweit rund hunderttausendfach eingesetzt.

Es hat mich manchmal irritiert, dass man mich ins kalte Wasser warf und ich mir alle Themen und Zusammenhänge allein erarbeite musste und die indischen Kollegen es nicht schaffen kritische Lösungen innerhalb von 1 Woche zu implementieren. Obwohl es meinerseits sogar noch weniger Aufwand verursachen würde und ihre Ausbildung meinerseits und von anderen Kollegen extrem gut war. Mir ist vorletzte Woche der Kragen geplatzt und eine Beschwerde ging ans Management. Das ist mir in der bisherigen Laufbahn als Entwickler erst zweimal in 10 Jahren passiert.

Ein positives Beispiel: Aktuell wird ein indische Kollege, welcher bisher 2-3 Jahren in deutschsprachigen Ländern verbracht hat, von mir "ausgebildet". Seine Fortschritte sind sehr gut, wenn man die letzten 6 Monate berücksichtigt. Wir sprechen hauptsächlich englisch.

Ich würde sagen es ist sehr unterschiedlich. Nur manche Geschäftsführer stellen sich Outsourcing einfach viel zu leicht vor.

[StarGoose]

wenn man das hört das du da 6 monate lang jemanden erst ausbilden musst fragt man sich ob das wirklich was bringt und nicht schlicht ein kollege am nachbartisch viel viel sinnvoller wäre^^

[Gast]

@StarGoose: Der Kollege ist frisch von der Uni und war ein Ersatz für einen Abgänger. Ich habe ein anderes Thema betreut, welches von einem Team in Indien nun bearbeitet wird. Systemkritische Software für Kunden, die Millionen dafür zahlen. Downtimekosten > 100 000 € am Tag? Wieviel Einarbeitungszeit glaubst du haben Erfahrene neue Kollege bei uns? Wir schätzen in der Regel ebenfalls 3-6 Monate.

[StarGoose]

bei downtimekosten von über 100k am tag frag ich mich wie man so blöd sein kann und sich mit outgesourcten kräften die von der materie wohl keine ahnung haben rumschlägt oder mit kräften frisch von der uni
aber ich verstehe ja so viele dinge im leben nicht da macht das nun auch nix mehr^^

[Shink]

Die Entwickler behaupten, für die Umsetzung brauchen sie xyz Stunden. Die können sie nicht leisten, da fehlen die Kapazitäten: Die Leute haben genug um die Ohren, die Büros sind alle voll - wie will man so auch in Zukunft noch wachsen? Man kann den Auftrag sausen lassen. Man kann eine Konkurrenzfirma damit beauftragen (wobei: wofür ist man dann selbst noch gut?) Oder... Naja.

Dann gibt es noch so ne Sache:
Schön langsam bzw. je nach Region geht der Vorrat an "frisch-von-der-Informatikuni"-Kräften aus.
Was macht man also als Manager? Erfahrene Leute einstellen, die für den eigenen Posten besser geeignet sind als man selbst?

[Exxtreme]

Dann gibt es noch so ne Sache:
Schön langsam bzw. je nach Region geht der Vorrat an "frisch-von-der-Informatikuni"-Kräften aus.
Was macht man also als Manager? Erfahrene Leute einstellen, die für den eigenen Posten besser geeignet sind als man selbst?
Man könnte ja selber ausbilden. Aber nein. Der Staat soll ja für den Nachwuchs an Arbeitskräften sorgen. :rolleyes:

[StarGoose]

oder lieber mal den mitbewerber einspannen als die kohle nach indien gehen zu lassen und sich damit mehr ärger einzuhandeln als gut ist^^

bessere auslastung dort würde vielleicht auch mehr auszubildende bewirken und mehr know how das im land bleibt usw

oh und wachstum um jeden preis war und ist noch nie gut
man kann einen lukrativen auftrag wegen kapazitätsmangel auch ablehnen oder um aufschub bitten

aber da sitzt immer ein kleiner dagobert irgendwo und hat die dollarzeichen in den augen und will mehr mehr mehr
es ginge aber auch anders nur halt nicht mit leuten die auf dem altar des wachstums um jeden preis alles opfern

[Shink]

Man könnte ja selber ausbilden. Aber nein. Der Staat soll ja für den Nachwuchs an Arbeitskräften sorgen.
Da hast du natürlich recht. Wobei: Ist es wirklich so schwer, mit frei erhältlichen Wissensquellen Software Entwickler zu werden, wenn es einen interessiert? Hat man so wirklich keine Chance am Markt?

da sitzt immer ein kleiner dagobert irgendwo und hat die dollarzeichen in den augen und will mehr mehr mehr
es ginge aber auch anders nur halt nicht mit leuten die auf dem altar des wachstums um jeden preis alles opfern
Es gibt immer wieder für die unterschiedlichsten Leute individuell nachvollziehbare Gründe, besonders ehrgeizig zu sein. Was will man dagegen machen?:freak:
Solange die Nachfrage so groß ist (und ich wage zu behaupten, dass das zur Zeit der Fall ist), werden wir uns immer wieder mit diesen Problemen herumschlagen müssen.

[Exxtreme]

Da hast du natürlich recht. Wobei: Ist es wirklich so schwer, mit frei erhältlichen Wissensquellen Software Entwickler zu werden, wenn es einen interessiert? Hat man so wirklich keine Chance am Markt?


Ohne eine staatliche Urkunde, die bescheinigst, dass du etwas kannst, kannst du offiziell nix. :freak:

[Shink]

Kommt auf die Nachfrage an. Bei uns ist es - zumindest zur Zeit - definitiv anders. Wir haben zwar lustige Einstiegstests aber Diplom braucht man definitiv keines - es haben hier in letzter Zeit auch Studienabbrecher, Fachkräfte (ich nehme an ohne Diplom) aus dem nahen Osten etc. angefangen.

[Thunderhit]

Ist nur die Frage, wo man dann einsteigt und was man dann macht, hm?

[Shink]

Ist nur die Frage, wo man dann einsteigt und was man dann macht, hm?
Wenn man als Programmierer einsteigen will, Programmieren kann und wir Programmierer brauchen, dann als Programmierer.:rolleyes: