Technische Anforderungen
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.
Oder nutzen Sie das Golem-pur-Angebot
und lesen Golem.de
- ohne Werbung
- mit ausgeschaltetem Javascript
- mit RSS-Volltext-Feed
Software-Projekte: Meine Erfahrungen mit einer externen Entwicklerfirma | Minimum Viable Programming |
Mir sagt der ganze Artikel, dass er vermutlich aus Indien berichtet. Warum? - Lohnniveau...
Ich habe nichts zum Preis geschrieben! Ich schriebe nur dass der Firmengründer zahlreiche...
Es ist bekannt das Asiaten alles können, aber alles nur viel blabla ist.
Das verdient man bei 160 Stunden und 25¤ hier aber nicht. Zumindest wenn das Unternehmen...