Ist es möglich, ein fehlgeschlagenes ausgelagertes Projekt (in 9 Monaten) zu retten?

Aus meiner Erfahrung funktionieren ausgelagerte Projekte nur, wenn:

• Sie als Kunde bleiben in die Entwicklung des Produkts eingebunden. Sie geben dem Anbieter nicht einfach etwas zu tun und erwarten, dass er in 6 Monaten oder was auch immer liefert. Sie nehmen nicht einfach „Ihre Pfötchen“ in das Projekt. Es geht um die kontinuierliche Zusammenarbeit mit dem Anbieter, um an Ihren Zielen zu arbeiten.
• Sie haben Vertrauen in die Fähigkeiten der Mitarbeiter, die der Dienstleister für Sie eingesetzt hat. Das heißt, Sie hatten Interviews mit ihnen, bevor Sie dem Anbieter erlaubten, sie Ihrem Projekt zuzuweisen. Bitten Sie niemals einen Anbieter, Ihnen etwas so zu liefern, wie er es für richtig hält. Was sie liefern, ist genauso wichtig wie wie sie liefern. Das „Wie“ zu ihrem eigenen Geschäft zu machen, ist eine schlechte Idee.
• Sie müssen einen iterativen und inkrementellen Ansatz verwenden, wenn Sie mit einem neuen Anbieter arbeiten. Sie müssen auch jemanden an Ihrer Seite haben, der alle Aspekte der Ergebnisse bewerten kann, einschließlich eines Blicks unter die Haube. Wenn Ihnen das, was Sie sehen, nicht gefällt und der Anbieter es nicht verbessern kann oder Ihnen das Tempo der Verbesserung nicht gefällt, können Sie dann einen Punkt machen, anstatt 9 Monate zu warten, um herauszufinden, dass Sie ein großes Durcheinander haben an deinen Händen.
• Sie müssen bedenken, dass dies immer noch Ihr Projekt ist, nicht das Projekt des Anbieters.

Auf die Gefahr hin, einen schamlosen Stecker zu setzen, das, was Sie beschreiben, ist das, worüber ich im Outsourcing-Kapitel meines Buches gesprochen habe . Ich kann diesen Inhalt hier nicht vollständig wiedergeben, daher füge ich einige mögliche Erklärungen zu den Dingen hinzu, die Sie in Ihrer Frage erwähnt haben.

Trotz vieler Ecken und Kanten schienen sie bei der Erledigung der Aufgaben gute Fortschritte zu machen, und sie versicherten uns immer wieder, dass bis zum Fertigstellungstermin alles aufgeräumt sein würde.

Du hast es nicht wirklich verifiziert! Sie sollten überprüft haben, ob der Fortschritt echt ist. Wenn das Projekt durch den Kalender voranschreitet, bedeutet das nicht, dass Sie gute Fortschritte machen und dass alles vor Ablauf der Frist abgeschlossen sein wird. Projekte verspäten sich einen Tag nach dem anderen, aber die Dinge werden falsch, mit Verzögerung oder absichtlich falsch kommuniziert, bis Sie irgendwann alle schlechten Nachrichten gleichzeitig erhalten.

Das Projekt war ursprünglich für 6 Monate geplant, aber jetzt, 9 Monate später, wird immer noch daran gearbeitet.

War das ein neuer Anbieter? Sie hätten einen Time-and-Material-Vertrag verwenden sollen , aber anscheinend haben Sie sich stattdessen für einen Festpreis entschieden . Wenn Sie dem Anbieter nicht vertrauen (wenn Sie zuvor mit ihm zusammengearbeitet haben und er eine gute Erfolgsbilanz vorweisen kann oder er von jemandem, dem Sie vertrauen, aus dem gleichen Grund, aus dem er zuvor mit ihm zusammengearbeitet hat, wärmstens empfohlen wird), sollten Sie immer die Möglichkeit eines Projektversagens in Betracht ziehen . Anscheinend nicht. Und wie David Espina in seinem obigen Kommentar erwähnte, könnten Sie es immer noch nicht in Betracht ziehen, obwohl die Beweise reichlich vorhanden sind, dass dies ein Fehlschlag ist.

Das Hauptproblem, das wir haben, ist, dass die Codierung scheinbar willkürlich/nachlässig von Leuten durchgeführt wurde, die uns als „leitende Entwickler“ beworben wurden, aber in Wirklichkeit wahrscheinlich über ein Einstiegs-Fähigkeitenset verfügen.

Sie haben sich nicht die Zeit genommen, die Leute zu kennen, die an Ihrem Projekt gearbeitet haben, wie ich oben erwähnt habe. Sie betrachteten dies als eine Blackbox mit Eingaben von Ihnen auf der einen Seite und Ausgaben des Dienstanbieters auf der anderen Seite. Sie sollten immer wissen, was in der Blackbox vor sich geht, wer wie an Ihrem Projekt arbeitet.

Eine kleine Auswahl der vielen, vielen Probleme, auf die wir stoßen, [...]

Die Liste der Probleme, die Sie dann weiter beschreiben, sind dumme Fehler, die ein Beweis für unerfahrene Entwickler sind. In guten ausgelagerten Projekten sollten die Probleme hauptsächlich auf Missverständnisse der Anforderungen oder der Domäne oder auf Kommunikationsprobleme zurückzuführen sein. Was Sie weiter beschreiben, sind technische Probleme. Der Code ist schlecht geschrieben. Erfahrene Entwickler werden diese Art von Fehlern nicht so oft machen, aber Fehler der Art, die ich gerade erwähnt habe. Es ist offensichtlich, dass ihre Fähigkeiten fehlen.

Es fühlt sich an wie der Tod durch 1.000 Schnitte

In der Tat. Und um dies zu flicken, werden 1.000 Bandagen benötigt.

Wir haben viel gelernt, und wenn wir zum Anfang zurückgehen könnten, würden wir vieles anders machen – Dinge wie das Interviewen und Auswählen von Entwicklern, das Erstellen kleinerer, überschaubarerer Bereiche für Ergebnisse, einen besseren Plan zum Durchziehen raus ggf. etc.

Betrachten Sie es als eine Lektion gelernt. Manchmal zahlt man viel für eine Lektion. Stellen Sie sicher, dass Sie dieses Wissen für dieses oder andere Projekte nutzen.

Aber dafür ist es jetzt zu spät, und wir haben ihnen bereits 2/3 des vereinbarten Geldes gezahlt.

Anstatt also zwei Drittel des Geldes zu verlieren, wollen Sie das ganze Geld verlieren? Glauben Sie absolut, dass dies gerettet werden kann und es sich lohnt, noch mehr Geld dafür zu investieren? Oder sind Sie, wie David Espina erwähnt hat, sicher, dass Sie nicht auf den Fehlschluss der versunkenen Kosten hereinfallen ?

Wir haben zwar darüber nachgedacht, dass die Entwickler ersetzt werden, aber ich weiß nicht, wie lange es dauern würde, bis neue Entwickler auf dem neuesten Stand sind, als diejenigen, die seit 9 Monaten an dem Projekt sind, oder ob sie es tun würden sogar besser sein.

Sie haben keine Garantie dafür, dass sie bessere Entwickler sind, es sei denn, Sie interviewen sie selbst und stellen sicher, dass sie tatsächlich diejenigen sind, die an Ihrem Projekt arbeiten. Die Frage, die Sie sich stellen sollten, ist, warum sie überhaupt Einsteiger eingestellt haben und warum sie als Senioren beworben wurden?

Ihre nächsten Punkte zeigen, dass sie immer noch nicht wissen, was sie tun, weil sie ihre Probleme nicht lösen. Sie scheinen Zeit zu kaufen und Sie noch mehr in das Projekt zu investieren, um weiterhin Zahlungen von Ihnen zu erhalten.

[...] was kann getan werden, um das Projekt wieder auf Kurs zu bringen?

Sie entweder:

• glauben Sie ihnen weiterhin, vertrauen Sie ihnen und fahren Sie mit dem Projekt fort, mit dem Risiko, immer tiefer in den möglichen Verlust einzudringen. An diesem Punkt müssen Sie die Entwicklung vollständig stoppen und sich darauf konzentrieren, die Probleme zu beheben. Die Reparatur muss von einer ganzen Reihe von Regressionstests begleitet werden, die sicherstellen, dass sie, sobald sie etwas repariert haben, repariert bleiben und nicht durch weitere Arbeit später wieder kaputt gehen. Sie müssen in automatisierte Tests investieren, die Ihnen nichts bringen, Ihnen aber ein besseres Vertrauen geben, dass das Ding nicht vollständig auseinanderfällt (beachten Sie, dass dieselben Entwickler diese Tests schreiben müssen, also wird ihre Qualität sein genauso schlecht wie der Code, den sie testen). Oder...
• Sie müssen das Projekt vollständig beenden. Bitten Sie sie, Ihnen alle Ergebnisse zu liefern, auf die Sie sich zu Beginn des Projekts geeinigt haben - in welchem ​​​​Zustand sie auch sind - und lassen Sie jemanden, dem Sie vertrauen, auf Ihrer eigenen Seite alles bewerten. Dies wird Ihnen sagen, ob das Ding geborgen werden kann oder ob es für Schrott geeignet ist. Sobald Sie das wahre Ausmaß des Schadens bewertet und kennen, sind Sie besser in der Lage, eine Entscheidung zu treffen: Abbrechen oder fortfahren (vielleicht mit ihnen oder mit einem anderen Anbieter, auf die gleiche Weise oder iterativ).

Ich hätte das mit einer ermutigenden Bemerkung beenden wollen, aber meiner Erfahrung nach sind die Dinge mit dem, was Sie beschreiben, nicht zu retten.

Es wird immer eine Menge Meinungen über den Ansatz geben, der gewählt wird, wenn rückblickende Vorurteile die Kontrolle übernehmen, und diese Meinungen werden so offensichtlich erscheinen. Eine qualitativ hochwertige Lessons-Learned-Analyse wäre angebracht, aber Sie müssen die Post-hoc-Ergo-Propter-Hoc-Schlussfolgerungen vermeiden.

Großartige Piloten und großartiges Fliegen werden einen abprallen lassen oder von Zeit zu Zeit sogar abstürzen. Dies könnte der Absturz Ihres ausgelagerten Teams gewesen sein. Ihr nächster Entwicklungsaufwand könnte herausragend sein.

Was Sie zuerst tun müssen, ist das Projekt vollständig zu stoppen. Stoppen Sie das Drehen des Schraubenschlüssels und hören Sie auf, Geld auszugeben. Überprüfen Sie dann, was geliefert wurde, und prüfen Sie, ob es eines dieser Arbeitsergebnisse gibt, das für die weitere Arbeit in der Zukunft nützlich wäre. Führen Sie eine überzeugende, durchdachte Obduktion durch. Nehmen Sie dann dieses Projekt und vergleichen Sie es mit Ihren anderen Projekten und priorisieren Sie neu, was Sie und Ihr Unternehmen tun möchten.

Ihre bisherigen Kosten und Ihr Aufwand sind gesunken. Gehen Sie davon weg und denken Sie nicht darüber nach, was für Ihre Bemühungen zur Neupriorisierung ausgegeben wurde. Betrachten Sie dieses Projekt, als wäre es brandneu, und schlagen Sie seinen Business Case mit anderen konkurrierenden Projekten. Dann marschiere weiter.

Viele gute Punkte von @bogdan.

Die Frage von mir ist: " Wie sehr sind Sie daran interessiert, dies zu retten, und welche Mittel stehen Ihnen zur Verfügung, um es zu retten (dh Mandat)? "

Ich habe einige Erfahrung im Umgang mit Softwareentwicklungsprojekten, einschließlich Offshore-Projekten. Wenn Sie sich an mich wenden und mich bitten würden, „bitte dieses Projekt zu retten“, würde ich nach Indien reisen, vielleicht mit einem leitenden Entwickler/Architekten, und tun, was Bogdan sagt:

An diesem Punkt müssen Sie die Entwicklung vollständig stoppen und sich darauf konzentrieren, die Probleme zu beheben.

Gehen Sie die Elemente durch, priorisieren Sie sie, lassen Sie sie beheben, lassen Sie den leitenden Entwickler/Architekten bei Herausforderungen im Zusammenhang mit der Codequalität, „wiederkehrenden und seltsamen Fehlern“, verwendeten Frameworks usw. helfen. Arbeiten Sie sich durch den Rückstand, ein Element nach dem anderen und das System stabilisieren.

In der Praxis übernimmst du die Kontrolle über das Team und was es tut. Sie priorisieren, sie liefern. Und Ihre technische Unterstützung wird kontinuierlich überprüft.

Haftungsausschluss: keine Informationen über die Größe des Projekts, des Vertrags, der derzeit beteiligten Arbeitskräfte. Wenn wir also von 200 Entwicklern sprechen, ist möglicherweise ein anderer Ansatz erforderlich.

Die Tatsache, dass Sie Probleme mit so vielen Dingen gleichzeitig haben, bedeutet vielleicht, dass Sie nicht inkrementell liefern und testen. Diese mehrfachen Besprechungen, um "alle Anforderungen und dokumentierten Probleme" zu besprechen, können Teil des Problems sein - ich glaube nicht, dass Sie eine solche Arbeit durchführen können. Ich schlage Ihnen stattdessen vor, die Fehler und Änderungen in einem Rückstand zu priorisieren , sie in jeweils einer kurzen Iteration anzugehen, Ihre Regressionstests zu automatisieren und dann sicherzustellen, dass Sie sich stetig vorwärts bewegen.

Wenn Sie noch nicht wirklich "live" sind, dann sollten Sie über Ihre Veröffentlichungsplanung nachdenken. Denken Sie daran, dass solche Lösungen im Allgemeinen nie "vollständig" sind, bis Sie sie nicht mehr verwenden. Planen Sie eher einen kontinuierlichen Arbeitsrückstand und eine kontinuierliche Verbesserung als eine perfekte Fertigstellung ein. Entscheidend ist, welche Funktionalität Sie wann liefern können.

Wenn Sie das Vertrauen in das Entwicklungsteam verloren haben und davon ausgehen, dass Sie das gesamte geistige Eigentum besitzen, sollten Sie unbedingt den Dienstanbieter wechseln.