Письма римскому другу
Ещё один текст на немецком. Так как вещи банальные и уже было, то без перевода. Немецкий не блестящий, просто как заготовка.
Standardisierung und andere Irrtümer im Outsourcing
Nur wenige Projekte im Outsourcing der Softwareentwicklung sind erfolgreich. In meisten Fällen können die geplanten Budget, Zeit und Qualität nicht erreicht werden. Die Auftraggeber wissen das und suchen "sichere Methoden", die es erlauben, mit Outsourcing ohne Risiko Geld zu sparen. Selbstverständlich gibt es Berater, die für solche Methoden werben.
Leider kann das in den realen Projekten nicht funktionieren.
Es ist ziemlich leicht die Dilettanten in etwas zu überzeugen, was sie nicht verstehen, und "sichere Methoden" oder "geprüfte Lösungen" zu verkaufen. Aber ist es besser zu verstehen, wie und warum diese Lösungen funktionieren, und was sie kosten würden. Das erklären die Berater und seine Präsentationen nicht.
Meine Erfahrungen und die Daten aus verschiedenen Projekten zeigen, dass die Softwareentwicklung eine geistliche Tätigkeit ist, und dass es keine Prozesse gibt, die gute Leute ersetzen können.
Es ist unmöglich die Standards zu herstellen, die die Qualität der IT Fachleute definieren. Einige listen die notwendige Erfahrungen, aber keine Diplome und Zertifikate bestätigen, dass die Leute seine "geprüfte Kenntnisse" erfolgreich verwenden können. (Ich sehe oft Beispiele, die wirklich schrecklich sind.)
Es ist auch nützlich die reale Daten aus ersten Händen zu bekommen. Ich habe einmal eine Präsentation über eine "erfolgreiche Einführung den neuen Methoden" den Leuten gegeben, die in diesem Unternehmen mit dieser Technologie wirklich arbeiteten. Sie haben sehr viel über der Sicht des Managements gelacht.
Wenn die Leute gut sind, funktionieren alle "moderne Methoden" ziemlich gut. Andererseits zeigen in diesen Bedingungen auch die "chaotische" oder "intuitive" Prozesse gleich gute Ergebnisse. In vielen Fällen werden die Formalitäten nur stören. Wenn die Leute schlecht sind, werden keine Standards helfen.
Ich würde empfehlen für Outsourcing gute Kontrolle und hohe Flexibilität den "geprüften Lösungen" bevorzugen. Von der "hohen Kostentransparenz" und anderen Mikromanagement-Methoden würde ich eher abraten. Das ist in meisten Fällen kontraproduktiv.
Meine Erfahrungen zeigen, dass die Auftragnehmer je mehr lügen je schwieriger es ist, sie intern zu prüfen. Das trifft Outsourcing besonders hart. So haben wir in einem Projekt festgestellt, dass aus 6 "Experten" nur einer in der angebotener Technologie irgendwelche Kenntnisse hatte. In einem anderen Projekt haben die Leute mehr als 24 Stunden pro Arbeitstag kalkuliert.
Und das waren die Firmen in Westeuropa. Mit Indien und China ist alles 10 mal schlimmer. CMMI und ISO helfen nicht besonders gut.
In solchen Bedingungen werden die "sichere Methoden" nur als einen Grundgerüst für bürokratische Täuschung der Arbeitsprozessen dienen. Andererseits braucht man Best Praxises und Richtlinien, besonders die Richtlinien für Aufgabenstellung und Kommunikation. Leider ist dieses Know-How mit bitteren Erfahrungen verbunden und geht gewöhnlich nicht nach außen.
Das Hauptproblem ist das Anforderungsmanagement.
Die meisten kleinen, mittleren und viele großen Unternehmen sind nicht in der Lage, die Anforderungen korrekt und vollständig zu schreiben. So brauchen sie immer die Leute vor Ort um die "fast fertige" Projekte zu korrigieren. Manchmal explodieren die Budgets auf solcher weise in 200-300%.
Es gibt ziemlich wenig Probleme bei rein technischen Aufträgen, wo die Anbieter die Anforderungen selbst vorstellen können. Wenn die interne Know-How oder spezifische Kenntnisse des Auftraggebers notwendig sind, enden die Projekte gewöhnlich nicht besonders erfolgreich.
Den Outsourcing-Anbietern schlage ich immer vor, die guten Anforderungsmanager bei Kunden zu halten, um Anforderungen und Änderungen rechtzeitig und vollständig zu bekommen. Das funktioniert.
Das zweite Problem ist die Kontrolle. Die Auftragnehmer verstehen häufig die Qualitätskriterien anders, als von den Auftraggeber erwartet ist. Manchmal wird die Qualität einfach ignoriert.
Es ist sinnvoll bei der Arbeit mit unbekannten Anbietern einen QA-Experte zu haben, der die Prozesse und die Zwischenergebnisse prüfen kann. So kann man z.B. rechtzeitig feststellen, dass die Qualität des Quellcode nicht stimmt oder die angebotene Software-Architektur für die großen Datenmengen nicht geeignet ist. Im schlimmsten Fall kann man die Zusammenarbeit rechtzeitig stoppen und damit Geld sparen. Es gab Projekte, wo für jeden indischen Programmierer zwei Leute vor Ort notwendig waren, um die outgesourste Software zu prüfen und zu korrigieren.
Leider sind nur wenige Unternehmen bereit, solche Verfahren zu verwenden. Kleine und mittlere Auftraggeber wollen gewöhnlich kein Geld in Anforderungs- und Qualitätsmanagement stecken. "Wir zahlen, sie machen. Wir möchten nicht, unsere Zeit zu opfern, um dumme Fragen zu beantworten. Wenn wir das Ergebnis bekommen, werden wir sagen, was falsch ist"
Andererseits gibt es wenig Leute, die gute Anforderungen schreiben können. Die meisten verfassen lange unsinnige Dokumente und malen realitätsfremde UML Diagramme. Die meisten Qualitätsmanager sind auch nicht in die Lage, mit den Frühindikatoren zu arbeiten, und können nur auf die fertige Software warten, um festzustellen, dass alles falsch gelaufen ist.
Standardisierung und andere Irrtümer im Outsourcing
Nur wenige Projekte im Outsourcing der Softwareentwicklung sind erfolgreich. In meisten Fällen können die geplanten Budget, Zeit und Qualität nicht erreicht werden. Die Auftraggeber wissen das und suchen "sichere Methoden", die es erlauben, mit Outsourcing ohne Risiko Geld zu sparen. Selbstverständlich gibt es Berater, die für solche Methoden werben.
Leider kann das in den realen Projekten nicht funktionieren.
Es ist ziemlich leicht die Dilettanten in etwas zu überzeugen, was sie nicht verstehen, und "sichere Methoden" oder "geprüfte Lösungen" zu verkaufen. Aber ist es besser zu verstehen, wie und warum diese Lösungen funktionieren, und was sie kosten würden. Das erklären die Berater und seine Präsentationen nicht.
Meine Erfahrungen und die Daten aus verschiedenen Projekten zeigen, dass die Softwareentwicklung eine geistliche Tätigkeit ist, und dass es keine Prozesse gibt, die gute Leute ersetzen können.
Es ist unmöglich die Standards zu herstellen, die die Qualität der IT Fachleute definieren. Einige listen die notwendige Erfahrungen, aber keine Diplome und Zertifikate bestätigen, dass die Leute seine "geprüfte Kenntnisse" erfolgreich verwenden können. (Ich sehe oft Beispiele, die wirklich schrecklich sind.)
Es ist auch nützlich die reale Daten aus ersten Händen zu bekommen. Ich habe einmal eine Präsentation über eine "erfolgreiche Einführung den neuen Methoden" den Leuten gegeben, die in diesem Unternehmen mit dieser Technologie wirklich arbeiteten. Sie haben sehr viel über der Sicht des Managements gelacht.
Wenn die Leute gut sind, funktionieren alle "moderne Methoden" ziemlich gut. Andererseits zeigen in diesen Bedingungen auch die "chaotische" oder "intuitive" Prozesse gleich gute Ergebnisse. In vielen Fällen werden die Formalitäten nur stören. Wenn die Leute schlecht sind, werden keine Standards helfen.
Ich würde empfehlen für Outsourcing gute Kontrolle und hohe Flexibilität den "geprüften Lösungen" bevorzugen. Von der "hohen Kostentransparenz" und anderen Mikromanagement-Methoden würde ich eher abraten. Das ist in meisten Fällen kontraproduktiv.
Meine Erfahrungen zeigen, dass die Auftragnehmer je mehr lügen je schwieriger es ist, sie intern zu prüfen. Das trifft Outsourcing besonders hart. So haben wir in einem Projekt festgestellt, dass aus 6 "Experten" nur einer in der angebotener Technologie irgendwelche Kenntnisse hatte. In einem anderen Projekt haben die Leute mehr als 24 Stunden pro Arbeitstag kalkuliert.
Und das waren die Firmen in Westeuropa. Mit Indien und China ist alles 10 mal schlimmer. CMMI und ISO helfen nicht besonders gut.
In solchen Bedingungen werden die "sichere Methoden" nur als einen Grundgerüst für bürokratische Täuschung der Arbeitsprozessen dienen. Andererseits braucht man Best Praxises und Richtlinien, besonders die Richtlinien für Aufgabenstellung und Kommunikation. Leider ist dieses Know-How mit bitteren Erfahrungen verbunden und geht gewöhnlich nicht nach außen.
Das Hauptproblem ist das Anforderungsmanagement.
Die meisten kleinen, mittleren und viele großen Unternehmen sind nicht in der Lage, die Anforderungen korrekt und vollständig zu schreiben. So brauchen sie immer die Leute vor Ort um die "fast fertige" Projekte zu korrigieren. Manchmal explodieren die Budgets auf solcher weise in 200-300%.
Es gibt ziemlich wenig Probleme bei rein technischen Aufträgen, wo die Anbieter die Anforderungen selbst vorstellen können. Wenn die interne Know-How oder spezifische Kenntnisse des Auftraggebers notwendig sind, enden die Projekte gewöhnlich nicht besonders erfolgreich.
Den Outsourcing-Anbietern schlage ich immer vor, die guten Anforderungsmanager bei Kunden zu halten, um Anforderungen und Änderungen rechtzeitig und vollständig zu bekommen. Das funktioniert.
Das zweite Problem ist die Kontrolle. Die Auftragnehmer verstehen häufig die Qualitätskriterien anders, als von den Auftraggeber erwartet ist. Manchmal wird die Qualität einfach ignoriert.
Es ist sinnvoll bei der Arbeit mit unbekannten Anbietern einen QA-Experte zu haben, der die Prozesse und die Zwischenergebnisse prüfen kann. So kann man z.B. rechtzeitig feststellen, dass die Qualität des Quellcode nicht stimmt oder die angebotene Software-Architektur für die großen Datenmengen nicht geeignet ist. Im schlimmsten Fall kann man die Zusammenarbeit rechtzeitig stoppen und damit Geld sparen. Es gab Projekte, wo für jeden indischen Programmierer zwei Leute vor Ort notwendig waren, um die outgesourste Software zu prüfen und zu korrigieren.
Leider sind nur wenige Unternehmen bereit, solche Verfahren zu verwenden. Kleine und mittlere Auftraggeber wollen gewöhnlich kein Geld in Anforderungs- und Qualitätsmanagement stecken. "Wir zahlen, sie machen. Wir möchten nicht, unsere Zeit zu opfern, um dumme Fragen zu beantworten. Wenn wir das Ergebnis bekommen, werden wir sagen, was falsch ist"
Andererseits gibt es wenig Leute, die gute Anforderungen schreiben können. Die meisten verfassen lange unsinnige Dokumente und malen realitätsfremde UML Diagramme. Die meisten Qualitätsmanager sind auch nicht in die Lage, mit den Frühindikatoren zu arbeiten, und können nur auf die fertige Software warten, um festzustellen, dass alles falsch gelaufen ist.