Sündenböcke ohne Ende

Wenn es eine Konstante bei all dem gab, war es die völlige Weigerung der Entwickler, die Verantwortung für irgendetwas zu übernehmen. Bevor sie an einer Aufgabe arbeiteten, bekundeten sie hundertprozentiges Vertrauen in ihre Fähigkeit, tolle Ergebnisse zu liefern. Wenn sie ihre Versprechen nicht einhielten, gab es hingegen immer jemanden, dem sie die Schuld daran gaben.

Sie können nicht herausfinden, wie man das Twilio-SDK verwendet?
"Twilio Chat funktioniert nicht mit React Native."
(Tut es doch.)

Die Chat-Implementierung hätte alle privaten Unterhaltungen öffentlich zugänglich gemacht?
"Die Alternative ist zu kompliziert."
(Deshalb haben wir Sie engagiert.)

Sie können nicht herausfinden, warum ein bestimmter Bildschirm 30 Sekunden zum Laden braucht?
"Wir müssen 5 API-Aufrufe machen und das verlangsamt es."
(Diese 5 API-Aufrufe brauchen zusammen weniger als 1 Sekunde.)

Das Projekt hat dreimal länger gedauert als versprochen?
"Die Server-API war sehr schlecht und fehlerhaft."
(Ja, ich bin sicher, das hat nichts mit Ihrer mangelnden Priorisierung, Kompetenz und Ihren Kommunikationsmethoden zu tun.)

Das Frustrierende an der Sache ist, dass dieser Ansatz funktioniert! Wenn ich nicht selbst Entwickler wäre, hätte ich alles geglaubt, was die Firma erzählt hat. Es gibt einen Grund, warum sie die direkte Kommunikation mit ihren Entwicklern blockiert - ihre Projektmanager sind Experten im Plaudern, selbstsicher und gut im Abwehren von Schuldzuweisungen. Wer sie anheuert, aber nicht die technischen Fähigkeiten hat, ihre Arbeit zu hinterfragen, ist wirklich zu bedauern.

Was ich daraus gelernt habe

Wenn man sich all die Dinge ansieht, die schiefgelaufen sind, wäre es sehr verlockend, einfach zu sagen: "Offshore-Entwickler sind schlecht." Das wäre aber nicht nur kleingeistig, sondern auch sehr limitierend. Aus Sicht von jemandem, der wie ich mit exzellenten Ingenieuren aus anderen Ländern zusammengearbeitet hat, ist es natürlich kompletter Blödsinn zu glauben, dass es nur in den USA gute Entwickler gibt.

Es ist auch verlockend, jetzt zu empfehlen, dass Sie Ihre Entwicklungsarbeit niemals auslagern sollten. Klar: Wenn Sie ein etabliertes Unternehmen wie Google oder ein VC-finanziertes Startup sind, ist es sinnvoll, alles selbst zu entwickeln und Entwickler mit sechsstelligen Gehältern zu beschäftigen. Aber für ein Bootstrapped-Startup mit einem kleinen Gründungsteam ist es mit Sicherheit gut, preiswertere Arbeitskräfte einzusetzen, die dabei helfen, Ihr MVP auf den Weg zu bringen. Es ist ein Ansatz, den wir schon bei anderen Gelegenheiten erfolgreich anwenden konnten.

Es ist auch sehr verlockend, dazu zu raten, sich gegen alles, was bei uns schiefgelaufen ist, schützen zu wollen, indem man bestimmte Vertragsklauseln aushandelt. Leider ist ein solcher Ansatz zum Scheitern verurteilt. Denn es gibt viel zu viele Unbekannte und zu viel Subjektivität, als dass man jemals alles in einem juristischen Dokument festhalten könnte. Ganz zu schweigen davon, dass die rechtliche Durchsetzung von Verträgen durch einen Rechtsstreit ein gewaltiges Unterfangen ist.

Letztlich gibt es nur eine wichtige Sache bei der Beauftragung eines Freelancers oder einer Entwicklerfirma: Sie müssen die Möglichkeit und das Drohpotenzial haben, den Auftrag zu kündigen, wenn die Entwickler keine gute Arbeit leisten. Fast jedes Problem, auf das wir gestoßen sind, rührte von unserem Mangel an Einflussmöglichkeiten her. Da wir so viel Geld im Voraus bezahlt hatten, hatten wir keine Möglichkeit, den Auftrag zu kündigen und jemand anderen zu beauftragen - nicht einmal, als alles sehr schlecht lief.

Ein besserer Weg

Als unser Vertrag auslief, trennten wir uns von der Firma und atmeten erleichtert auf. Ich spürte förmlich, wie mir eine riesige Last von den Schultern fiel. Von nun an änderten wir die Art und Weise, wie wir mit externen Entwicklern arbeiteten, radikal. Hier unsere Liste mit Empfehlungen:

1. Erstellen Sie eine fortlaufende Liste von Funktionen, die gebaut werden sollen.
2. Finden Sie eine Handvoll Entwickler, vorzugsweise unabhängige Freiberufler; aber auch eine Entwicklerfirma wäre in Ordnung, wenn sie mit den folgenden Abläufen einverstanden ist.
3. Wählen Sie für jeden Entwickler das Top-Feature aus der Liste aus und besprechen Sie die Anforderungen, Schätzungen und Kosten für das Feature.
4. Lassen Sie sie diese Funktion implementieren und testen.
5. Lassen Sie jemanden aus dem Unternehmen den Pull-Request überprüfen, die aktualisierte Anwendung testen und alle problematischen Punkte markieren.
6. Wenn Sie zufrieden sind, fügen Sie die Funktion zusammen und stellen Sie sie bereit, so dass alle Gründer/Nutzer die App kontinuierlich überprüfen und bei Bedarf Feedback geben oder Änderungen vornehmen können.
7. Wenn Sie mit der Arbeit der Entwickler zufrieden sind, wählen Sie die nächste Funktion aus, an der sie arbeiten sollen, und wiederholen Sie diesen Prozess.
8. Wenn Sie mit der Arbeit nicht zufrieden sind, trennen Sie sich von ihnen und suchen nach einem Ersatz.

Es war faszinierend zu sehen, um wie viel reibungsloser und angenehmer der Entwicklungsprozess war, nachdem wir uns von riesigen Vorabverträgen befreit und sie durch den oben beschriebenen, schrittweisen Ansatz ersetzt hatten. Unsere Entwickler waren angenehmer in der Zusammenarbeit, zeigten mehr Flexibilität, kommunizierten zuverlässiger mit uns und produzierten bessere Arbeitsergebnisse in kürzerer Zeit.

Das Beste von allem war, dass wir nicht mehr für längere Zeit an einen einzigen Anbieter gebunden waren, was uns große Sicherheit gab. Wenn wir einmal nicht zufrieden waren, wussten wir, dass wir eine Woche später wieder gehen konnten. Das hat uns einige Male gerettet und eine große Last von uns genommen.

Umgekehrt bin ich mir sicher, dass auch die Entwickler diese Flexibilität zu schätzen wussten. Unsere fortgesetzte Zusammenarbeit war etwas, auf das wir uns jede Woche einigten, nicht etwas, zu dem sie sich durch einen Vertrag gezwungen fühlten.

Ist es möglich, mit einem großen Wasserfall-Projekt erfolgreich zu sein, wenn man unseren Fehler vermeidet und den richtigen Entwicklungsdienstleister engagiert? Sicher, aber wie zuversichtlich sind Sie, dass Sie nicht die gleichen Probleme bekommen? Dieses ganze Debakel hat mir eine neue Wertschätzung für Agilität gegeben, und warum es entwickelt wurde.

• Zusammenarbeit mit dem Kunden statt Vertragsverhandlungen
• Individuen und Interaktionen über Prozesse
• Funktionierende Software statt umfassender Dokumentation
• Reagieren auf Veränderungen statt Befolgen eines Plans

Es hat sich herausgestellt, dass viele Entwicklungsfirmen sich weigern, auf diese Weise zu arbeiten und darauf bestehen, das Wasserfall-Modell zu verwenden, gepaart mit einem großen Vorabvertrag. Ich werde aber aufgrund meiner vorangegangenen Erfahrungen bei allen zukünftigen Unternehmungen auf der schrittweisen Vorgehensweise bestehen.