Ich versprach mir Hilfe für meine App-Entwicklung. Die externe Entwicklerfirma lieferte aber vor allem Fehler und Ausreden. Was ich daraus gelernt habe.
Dieser Text ist eine Übersetzung. Das Original des Software-Entwicklers Rajiv Prabhakar ist hier zu finden.
Vor vielen Jahren beschlossen eine jüngere, naivere Version meiner selbst und eine Bekannte von mir, neben unseren Vollzeitjobs ein Bootstrapping-Startup zu gründen, also ein Startup ohne Fremdkapital. Meine Mitgründerin brachte die Idee, die Produktvision und die Kontakte für die ersten Nutzer mit, ich war für die technische Entwicklung zuständig. Unser Plan für das MVP war, mit einer iOS- und Android-App zu starten.
Ich habe viel Erfahrung in der Backend-Entwicklung, eine mobile App hatte ich davor noch nie entwickelt. Anstatt zu versuchen, es von Grund auf zu lernen, entschieden wir uns, externe Entwickler mit der Erstellung der mobilen Apps zu beauftragen, während ich die gesamte serverseitige Entwicklung, P/SaaS-Integrationen und die Infrastruktur verwaltete.
Kontext
Die Zusammenarbeit mit externen Entwicklern war keine neue Erfahrung für mich, was mir, im Nachhinein betrachtet, ungerechtfertigtes Vertrauen gab. Für ein früheres Startup hatte ich mit einem jungen Teilzeit-Freelancer in einem anderen Land gearbeitet. Er war mir von jemandem, den ich kannte, empfohlen worden, machte eine tolle Arbeit und verlangte weniger als 10 Dollar pro Stunde.
Damals war mir das nicht klar, aber wenn man bedenkt, wie talentiert und gewissenhaft er war, war das ein Schnäppchen. Jetzt verdient er in San Francisco ein sechsstelliges Gehalt.
Leider war er für unser neues Projekt nicht mehr verfügbar. Meine Mitgründerin wollte außerdem eine renommiertere Firma für unsere Frontend-Entwicklung. Also entschieden wir uns, nach einem Dev Shop, also einer Entwicklerfirma, zu suchen und nicht nach einzelnen Freiberuflern.
Wir waren bei der Auswahl natürlich sorgfältig: Wir haben uns unabhängige Bewertungen Dritter angesehen, nach Referenzen gefragt, mit früheren Kunden gesprochen und uns bei mehreren Anbietern umgesehen, bevor wir uns schließlich für den entschieden haben, der uns am vertrauenswürdigsten schien. Die Firma verlangte etwa 25 Dollar pro Stunde - deutlich mehr als vergleichbare Freiberufler. Wir dachten aber, dass wir damit ein erfahrenes und professionelles Unternehmen beauftragen und nicht nur eine beliebige Einzelperson. Wir dachten, das sei das Beste für uns.
Meine Mitgründerin, eine Anwältin, und ich versuchten natürlich, unseren Vertrag mit der Firma so detailliert wie möglich zu gestalten. Da wir wussten, dass Softwareprojekte extrem anfällig für Kostenüberschreitungen sind, verhandelten wir einen Festpreisvertrag mit einer Garantie für alle Fehler. Nach langer Vorarbeit, in der wir die Vertragsdetails festgehalten und jede einzelne Funktion, die sie für uns bauen sollten, ganz genau beschrieben hatten, war es an der Zeit, die erste Zahlung zu leisten und mit dem Projekt zu starten.
Und genau hier haben wir einen entscheidenden Fehler gemacht.
Gemäß unserer Vertragsvereinbarung wurde das Projekt in drei Abschnitte aufgeteilt. Wir sollten 40 Prozent im Voraus bezahlen, bevor überhaupt irgendeine Arbeit geleistet wurde. Dann weitere 30 Prozent am Ende jedes der ersten beiden Abschnitte - und zwar, bevor wir die Ergebnisse des abgeschlossenen Abschnitts erhielten. In Anbetracht der Tatsache, dass es sich um ein Bootstrapping-Startup handelte und wir eine fünfstellige Vorauszahlung leisten mussten, ohne dass die Ergebnisse vor der nächsten Zahlung geliefert wurden, waren wir praktisch für die Dauer des gesamten Projekts gebunden.
Wir wussten das, dachten aber, dass es in Ordnung sei. Sie hatten gute Bewertungen aus unabhängigen Quellen, tolle Kundenreferenzen; Warnzeichen gab es nicht. Außerdem wussten wir, dass es nicht einfach ist, neue Entwickler in ein Projekt einzubinden, das von jemand anderem gemacht wird - also hatten wir ohnehin vor, das gesamte Projekt mit ihnen gemeinsam umzusetzen.
Im Nachhinein betrachtet war das die schlechteste technische Entscheidung, die wir getroffen haben, und das hat unser Startup ganz schön in Schwierigkeiten gebracht.
Eine der wichtigsten Funktionen für unsere App war ein Echtzeit-Chat. Während unserer Vertragsverhandlungen gaben uns die Entwickler einige SaaS-Empfehlungen, um die Erstellung der Echtzeit-Chat-Funktionalität zu vereinfachen - eine davon war Twilio Chat. Nach Prüfung der verschiedenen Empfehlungen schien Twilio die beste Option zu sein und wir einigten uns darauf, sie zu verwenden.
Als es an die Umsetzung ging, gerieten die Entwickler aber in eine Sackgasse: Sie konnten nicht herausfinden, wie man Twilio Chat mit React Native zum Laufen bringt - obwohl sie es waren, die Twilio Chat und React Native überhaupt erst empfohlen hatten.
Schlimmer noch: Anstatt uns die Wahrheit zu sagen und uns zu erklären, dass sie nicht weiterkamen, sagten sie uns einfach, dass Twilio Chat nicht mit React Native funktioniere - und wollten nun, dass wir zu einem völlig anderen Chat-Dienstleister wechseln (von einer Firma, von der wir noch nie gehört hatten), dass wir noch einmal von vorne anfangen und eine zusätzliche Gebühr für diesen Irrweg bezahlen (obwohl der Preis für das Projekt eigentlich fix sein sollte).
Das Schlimmste aber war, dass ihre Behauptung nicht einmal ansatzweise stimmte: Twilio Chat funktioniert einwandfrei mit React Native - sie wussten nur nicht, wie sie das hinbekommen sollten. Am Ende habe ich, ein Entwickler mit keinerlei React-Native-Erfahrung, viele Stunden mit der Lösungssuche verbracht und den Entwicklern dann beigebracht, wie es funktioniert. Und selbst, nachdem ich ihnen alles gezeigt hatte, brauchten sie mich immer noch, um ihnen Links zu Dokumentationen zu schicken und ihnen zu erklären, wie man die Twilio-APIs verwendet.
Hätte ich nicht herausgefunden, wie ich ihre Arbeit für sie erledigen kann, hätten wir ihre Empfehlung bestimmt befolgt. Wir hätten Twilio komplett aufgegeben und wären zu einem völlig anderen und minderwertigen Dienst gewechselt. Eine Entscheidung, die das Projekt um viele Monate und eine große Menge Geld zurückgeworfen hätte.
Nachlässige Sicherheit
Ich wünschte, ich könnte sagen, dass dies das Ende des Twilio-Debakels war, aber es kam noch schlimmer. Alle Twilio-Chatnachrichten sind Teil eines Channels, der entweder als "privat" oder "öffentlich" markiert werden kann. Wie der Name schon sagt, sind private Kanäle für die spezifischen Benutzer des Kanals gedacht, während öffentliche Kanäle von Nicht-Mitgliedern ''gesehen und ... betreten werden können. Außerdem sind der öffentliche Kanal und seine Mitglieder und Nachrichten für jeden Client-Endpunkt in einem bestimmten Dienst sichtbar.''
Ganz offensichtlich hätten also alle nicht-öffentlichen Nachrichten über private Kanäle implementiert werden müssen. Erstaunlicherweise implementierten unsere Entwickler aber alles über öffentliche Kanäle - was ich beim Durchsuchen der Twilio-Konsole feststellte. Wären wir so live gegangen, hätte jeder, der auch nur minimale Entwicklungserfahrung hat, die privaten Unterhaltungen jedes einzelnen Benutzers in der App belauschen können. Wenn ich das nicht selbst bemerkt hätte ... Die Entwicklungsfirma hätte ganz sicher keine Pen-Tester bezahlt, die solche Sicherheitsprobleme aufdecken.
Das war ein grober Fehler. Noch schockierender ist aber, dass die Entwickler, anstatt sich dafür zu entschuldigen, unseren Änderungswunsch zurückgewiesen haben. Offensichtlich ist es einfacher, die Chat-Funktionalität mit öffentlichen Kanälen zu implementieren - und so zog man es vor, es so zu lassen. Erst als wir stark darauf drängten, änderten sie die Implementierung.
Überall Bugs
Einer der Gründe, warum wir unbedingt eine externe Entwicklungsfirma beauftragen wollten (und nicht einzelne Freiberufler), war der Support, der uns versprochen worden war: vor allem ein QA-Team, das die App ausgiebig testen würde, bevor sie uns gezeigt wird.
Bugs sind in jedem Software-Projekt unvermeidlich. Wir wussten also, dass die Firma keine Versprechungen machen konnte. Aber wir haben sie beim Wort genommen, als uns gesagt wurde, dass wir nur mit ein paar wenigen Fehlern rechnen müssten.
Wie wir später herausfanden, war das völliger Unsinn. Jede einzelne ihrer Lieferungen war voll mit Fehlern. Selbst die grundlegendsten Funktionen gingen nicht - ich hatte sogar den Verdacht, dass sie die App nie mit echten Smartphones getestet hatten. Wenn sie sie überhaupt getestet hatten. Meine Mitgründerin und ich mussten eine ganze Woche lang jeden Tag mehrere Stunden damit verbringen, alle Bugs zu dokumentieren und akribisch zu überprüfen.
Ein Beispiel für einen solchen Fehler: Wenn ein Nutzer oder eine Nutzerin mehr als 50 Kontakte hatte, wurden nur die ersten 50 in der App angezeigt. Auf alle anderen konnte nicht zugegriffen werden. Es stellte sich heraus, dass eine unserer SaaS-Integrationen mit einer Paginierung arbeitete und die Entwickler Code implementiert hatten, bei dem nur die erste Seite der Ergebnisse angezeigt wurde.
Da dieser Fehler erst bei 51 Kontakten eines einzelnen Nutzers ausgelöst werden konnte und wir noch in der privaten Testphase waren, dauerte es eine Weile, bis wir darauf stießen. Als wir den Fehler gefunden hatten, meldeten wir ihn. Sie haben ihn sofort behoben. Wir testeten ihren Fix und er schien gut zu funktionieren.
Als ich mir den geänderten Code anschaute, wurde mir jedoch klar, wie unsauber ihre Lösung war. Anstatt eine While-Schleife zu verwenden, um alle Seiten zu laden, hatten sie einfach eine If-Bedingung hinzugefügt, um die zweite Seite zu laden. Sobald Nutzer mehr als 100 Kontakte hätten, wäre er der gleiche Fehler wieder aufgetaucht.
Den ersten Fehler hätte man als Versehen entschuldigen können. Der zweite war fahrlässig. Die Entwickler müssen sich gedacht haben, dass wir sehr lange brauchen würden, um die zweite Ergebnisseite auszugeben und noch länger für die dritte. Sie wussten, was sie taten, sie wussten um die Grenzen ihres "Fix", und sie taten es trotzdem. Wenn wir ihren Code nicht sorgfältig untersucht hätten, wäre dieser Fehler auch in die Produktion gelangt.
Keine Versionsgeschichte
Als Entwickler wusste ich aus eigener Erfahrung, wie nützlich eine Versionsgeschichte ist. Sie hilft zukünftigen Entwicklern zu verstehen, warum bestimmte Design-Entscheidungen getroffen wurden und wie bestimmte Funktionalitäten gebaut wurden. Außerdem bietet sie eine Vorlage für ähnliche Funktionen.
Während der Vertragsverhandlungen habe ich deswegen darauf bestanden, dass das endgültige Ergebnis ein Git-Repository sein sollte. Die Entwickler stimmten dem zu und sagten, dass sie auch intern Git verwenden. Als es an der Zeit war, uns den Quellcode zu liefern, schickten sie aber eine einzige Zip-Datei, die eine Mischung aus dem gesamten Quellcode und den generierten Dateien darstellte.
Ich erinnerte sie daran, dass sie sich vertraglich verpflichtet hatten, uns ein Git-Repository zur Verfügung zu stellen. Tatsächlich sah ich in der Zip-Datei, die sie uns geschickt hatten, sogar ein .git-Verzeichnis - was darauf hindeutet, dass sie Git für ihre Entwicklung verwendet hatten.
Am nächsten Tag schickten sie uns prompt ein Git-Repository. Es enthielt ein einziges Commit - das aus genau der gleichen Zip-Datei bestand, die wir am Tag zuvor erhalten hatten.
Ich schluckte meinen Ärger darüber herunter und sagte ihnen, dass wir die gesamte Versionsgeschichte haben wollten, nicht nur einen einzigen Commit, der die gleiche Zip-Datei enthielt. Sie antworteten, dass sie einige "sensible Informationen" in ihrem Git-Repository hätten, die nicht für ein externes Publikum bestimmt seien. Daher könnten sie diese nicht mit uns teilen. "Der Vertrag sagt nur, dass wir ein Git-Repository liefern sollen. Er sagt nicht, dass das Repository alle Entwicklungs-Commits und die Versionsgeschichte enthalten soll."
Während der Verhandlungen hatten wir mehrfach erwähnt, dass die serverseitigen APIs noch nicht vollständig implementiert sind und dass wir die Backend-Entwicklung parallel zur Frontend-Entwicklung machen wollten. Außerdem sagten wir, dass ich ihnen zu Beginn des Projekts alle API-Endpunkte zur Verfügung stellen würde, von denen einige vollständig implementiert wären. So konnten sie sofort mit der Arbeit an den einfacheren Funktionen beginnen und diese wenigen Endpunkte verwenden. Wenn sie die ersten Funktionen fertig hätten, wären die APIs bereit für die nächsten.
Unser Ziel war es, Verzögerungen zu vermeiden und parallel zu arbeiten, um so insgesamt früher mit der App starten zu können. Wir haben das immer wieder so gesagt - und uns wurde stets rückgemeldet, dass alles in Ordnung sei.
Sobald wir das Geld bezahlt hatten, änderte sich das aber. Plötzlich weigerten sich die Entwickler, überhaupt mit der Arbeit zu beginnen, bevor die Backend-Entwicklung zu 100 Prozent abgeschlossen war - und zwar für jede einzelne Funktion des gesamten Projekts.
Glücklicherweise war ich zu diesem Zeitpunkt mit der Backend-Entwicklung beinahe fertig, da wir viel Zeit mit Vertragsverhandlungen und Designarbeiten verbracht hatten. Also war das am Ende kein Problem. Aber ich war schockiert und sehr enttäuscht, dass sie die Versprechen, die ihre Vertriebsmitarbeiter zuvor gemacht hatten, nicht einhielten.
In den Vorgesprächen hatten sie quasi den roten Teppich für uns ausgerollt. Als es dann aber losging, gruben sie sich ein und bestanden darauf, dass alles ganz genau nach ihren Vorstellungen ablaufen sollte.
My Way oder Highway
Zum Beispiel verwendete ich, nach eingehender Prüfung aller Optionen, Swagger, um die API-Endpunkte, ihre Eingaben, Schemata, Beschreibungen und ihr Verhalten zu dokumentieren. So wurde die Dokumentation in den Code eingebettet, automatisch generiert und auf dem neuesten Stand gehalten. Die Swagger-GUI bietet außerdem die sehr angenehme Möglichkeit, alle API-Dokumentationen zu durchsuchen und sogar API-Aufrufe zu Testzwecken direkt von der GUI aus zu machen.
Leider hatte die Firma ein anderes Vorgehen. Die Entwickler weigerten sich also, Swagger als Dokumentationsquelle zu nehmen. Stattdessen bestanden sie darauf, dass wir ihnen ein Word-Dokument per E-Mail schickten, mit dem gleichen Inhalt wie dem in Swagger, aber mit ihren spezifischen Formatierungsanforderungen.
Wir diskutierten mehrere Tage lang, bevor sie schließlich nachgaben. Diese Einstellung zog sich jedoch durch den gesamten Entwicklungsprozess. Wir hatten die Entwickler beauftragt, mobile Apps unter Verwendung unserer Backend-APIs zu entwickeln. Sie waren aber sehr wählerisch, denn sie wollten, dass die APIs auf eine ganz bestimmte Weise funktionierten. Jedes Mal, wenn es eine philosophische Meinungsverschiedenheit über das API-Design gab, mussten wir ewig darüber debattieren.
Es ist möglich, dass all dies von ihrer Leidenschaft für API-Best-Practices rührte, aber ich vermute, dass es in erster Linie daran lag, dass sie ihre eigene Arbeit so unabhängig wie möglich machen wollten. Und an ihren Problemen, die benötigte Funktionalität mit einer bestehenden API zu implementieren.
Eine weitere große Überraschung nach dem Projektstart war die fehlende Kommunikation. In meinen früheren Projekten haben wir immer über Teamgrenzen hinweg direkt mit Technikern und Ingenieuren gesprochen, um Probleme besser verstehen und lösen zu können. Zu meiner Überraschung ließen unsere Entwickler das ausdrücklich nicht zu.
Gemäß der Richtlinien der Firma hatten wir nur einen Ansprechpartner, eine Projektmanagerin ohne Programmierfachkenntnisse. Trotz unserer Bitten durften wir nicht direkt mit den Entwicklern Kontakt aufnehmen, die an dem Projekt arbeiteten. Außerdem weigerte sich die Projektmanagerin auch, in Echtzeit über Chat zu kommunizieren. Sie bestand darauf, alles per E-Mail abzuwickeln.
Mit der Zeit führte dies zu großen Kommunikationsproblemen. Immer wenn die Entwickler eine Frage hatten oder etwas nicht wussten, schickten sie ihre Frage an die Projektmanagerin. Sie sammelte alle Fragen und schickte mir am Ende des Arbeitstages eine lange E-Mail. Meine Antwort sahen sie erst zu Beginn ihres nächsten Arbeitstages.
So brauchte selbst eine einfache Frage und Antwort 24 Stunden, um bearbeitet zu werden. Kompliziertere Diskussionen nahmen mehrere Tage in Anspruch, statt in einer 30-minütigen Chat-Sitzung besprochen und geklärt zu werden. Glücklicherweise erkannte die Firma gegen Ende des Projekts endlich, wie ineffizient dieser Prozess war und gab uns einen direkten Kontakt zu ihren Entwicklern. Leider war es da schon zu spät.
Wir wussten schon zu Beginn des Projekts, dass dies ein großes Problem werden könnte. Man versicherte uns aber, dass es nicht so kommen werde. Natürlich war es am Ende doch so. Es ist einfach sehr schwierig, agil zu sein, wenn man nur über eine E-Mail pro Tag kommunizieren darf.
Große Verzögerungen
Leider hatten die oben genannten Probleme reale Auswirkungen auf den Zeitplan: Was als Zwei-Monats-Projekt geplant war, dauerte am Ende sieben Monate. Das war schlecht für uns, da wir viele potenzielle Benutzer verloren, die nicht auf den Start warten konnten.
Rückblickend waren diese Verzögerungen überhaupt nicht überraschend, wenn man bedenkt, dass es unseren Entwicklerin an technischem Fachwissen mangelte, sie auf einer Wasserfall-Methode bestanden und sich weigerten, direkt über Chat oder Telefonanrufe zu kommunizieren. Aber ich vermute, dass das nicht die einzigen Probleme waren.
Ich denke vielmehr, dass sie zwischendurch andere Projekte hatten, die sie für lukrativer hielten, und deshalb die Arbeit, die sie eigentlich für uns machen sollten, herunterstuften. Das war vermutlich auch der Grund, warum sie mitten im Projekt einen großen Personalwechsel in ihrem Entwicklerteam vorgenommen haben.
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
Software-Projekte: Meine Erfahrungen mit einer externen Entwicklerfirma - Golem.de - Golem.de
Read More
No comments:
Post a Comment