Webanwendung beauftragen: Was Sie als Auftraggeber wissen müssen

Die meisten Menschen, die zum ersten Mal eine Webanwendung beauftragen, sind keine Entwickler. Sie führen ein Unternehmen, eine Abteilung oder ein Produkt und haben ein Problem, das eine Website nicht lösen kann: Mitarbeiter, die Daten zwischen Tabellen hin und her kopieren, Kunden, die ein Portal wollen, ein Prozess, der in E-Mail-Threads und im Kopf einer einzelnen Person lebt. Eine Webanwendung zu beauftragen ist der Weg, aus diesem Problem Software zu machen. Sie müssen den Code nicht verstehen, um das gut zu machen. Sie müssen aber verstehen, was der Entwicklungspartner von Ihnen braucht, wie die Arbeit strukturiert sein sollte und welche Teile des Vertrags Sie später schützen.

Dieser Leitfaden richtet sich an die Person, die den Auftrag unterschreibt, nicht an die, die den Code schreibt. Wenn Sie die Sicht des Anbieters wollen, haben wir beschrieben, was ein Auftrag zur Entwicklung einer individuellen Webanwendung umfassen sollte, sowie eine Checkliste für Einkäufer zum Vergleich von Anbietern. Hier geht es um Ihre Hausaufgaben und Ihren Vertrag.

Eine Webanwendung ist keine Website

Die Unterscheidung ist wichtig, weil sie Kosten, Zeitplan und die Art des Partners bestimmt, den Sie brauchen. Eine Website präsentiert Informationen. Besucher lesen sie, füllen vielleicht ein Formular aus. Eine Webanwendung arbeitet: Nutzer melden sich an, legen Daten an und ändern sie, stoßen Prozesse an und erwarten, dass das System sich Zustände merkt und Regeln durchsetzt. Ein Buchungssystem, ein Kundenportal, ein internes Werkzeug zur Freigabe von Bestellungen, ein Dashboard, das Daten aus dem ERP zieht: Das sind Anwendungen.

Dieser Wechsel bringt Anforderungen mit sich, die eine Website nie hat. Jemand muss das Datenmodell entwerfen. Jemand muss entscheiden, wer was sehen und ändern darf. Es gibt eine Datenbank, die gesichert werden muss, Integrationen, die am Leben gehalten werden müssen, und eine Angriffsfläche, die mit jedem Feature wächst. Eine Agentur, die Marketing-Websites in einem Page Builder baut, ist nicht automatisch der richtige Partner dafür, und ein Angebot, das wie ein Website-Angebot aussieht (ein paar Seiten, eine Designrunde, ein Launch-Termin), ist ein Warnsignal.

Was ein seriöser Partner vor dem Angebot braucht

Wenn ein Anbieter Ihnen nach einem Telefonat einen Festpreis schickt, hat er entweder geraten oder plant, später nachzuverhandeln. Ein Partner, der liefern will, fragt zuerst nach einer Reihe von Inputs. Wer sie im Voraus vorbereitet, spart Wochen und macht Angebote vergleichbar.

Beginnen Sie mit dem Problem, nicht mit der Lösung. Schreiben Sie auf, was aktuell passiert, wer beteiligt ist und wo es weh tut. "Unsere Außendiensttechniker erfassen Stunden auf Papier, das Büro tippt sie freitags ab, und die Rechnungsstellung ist immer zwei Wochen zu spät" ist mehr wert als eine Feature-Liste, weil der Partner damit das kleinste Ding vorschlagen kann, das das Problem löst.

Beschreiben Sie dann die Nutzer. Wie viele, in welchen Rollen, auf welchen Geräten, wie oft. Ein internes Werkzeug für 12 Kollegen auf Büro-Laptops ist ein völlig anderes Projekt als ein Portal für 5.000 Kunden auf dem Smartphone, auch wenn die Bildschirme ähnlich aussehen.

Listen Sie die Systeme auf, mit denen die Anwendung sprechen muss. Welche Systeme halten Daten, die die Anwendung braucht oder erzeugt? ERP, CRM, Buchhaltung, eine alte Access-Datenbank, die API eines Lieferanten? Bei Integrationen gehen Schätzungen am häufigsten daneben, also nennen Sie jedes System, auch die peinlichen.

Seien Sie ehrlich bei Budget und Zeit. Anbieter fragen nach dem Budget, weil es bestimmt, welchen von drei oder vier gangbaren Ansätzen sie vorschlagen sollten, nicht um alles auszugeben. Eine grobe Spanne ("zwischen 40.000 und 80.000 Euro für die erste Version") reicht. Dasselbe gilt für Termine: Eine Messe im März ist eine harte Vorgabe; "so schnell wie möglich" ist kein Datum.

Nennen Sie zuletzt die Vorgaben, die nicht verhandelbar sind. Daten müssen in der EU bleiben. Die Anwendung muss mit Ihrem bestehenden Single Sign-on funktionieren. Das Design muss Ihrer Corporate Identity folgen. Sagen Sie das früh, denn nachträglich einzubauen ist teuer.

Wie das Projekt laufen sollte

Ein gut geführtes Projekt hat erkennbare Phasen, und jede endet mit etwas, das Sie ansehen und freigeben können.

Discovery kommt zuerst und ist üblicherweise bezahlte Arbeit. Über ein bis drei Wochen interviewt der Partner die Menschen, die die Anwendung nutzen werden, sichtet Ihre Systeme und erstellt eine Spezifikation: den Umfang der ersten Version, eine grobe Architektur, ein Datenmodell und eine Schätzung, an der Sie ihn festhalten können. Wenn ein Partner anbietet, Discovery zu überspringen, um Geld zu sparen, verschiebt er das Risiko von seiner Seite des Tisches auf Ihre.

Dann folgt ein Prototyp. Manchmal sind das klickbare Bildschirme, manchmal eine dünne lauffähige Version mit echten Daten hinter ein paar Screens. Er existiert, um Missverständnisse aufzudecken, solange sie billig zu beheben sind. Rechnen Sie also damit, hier Ihre Meinung zu ändern, und erwarten Sie, dass der Partner das fördert.

Die Entwicklung läuft dann in kurzen Zyklen, typischerweise zwei Wochen, die jeweils mit einer Demo funktionierender Software enden statt mit einem Statusbericht. Sie sollten sich jederzeit in einer Testumgebung anmelden und sehen können, was existiert. Testen gehört zu jedem Zyklus, nicht in eine Phase am Ende, auch wenn es vor dem Launch meist eine eigene Abnahmephase gibt, in der Ihr Team echte Szenarien durchspielt.

Der Launch ist selten ein einzelner Abend. Bei allem, was einen bestehenden Prozess ersetzt, planen Sie eine Phase ein, in der alt und neu parallel laufen, und legen Sie vorher fest, wer entscheidet, wann das Alte abgeschaltet wird.

Der Betrieb ist die Phase, die Auftraggeber am häufigsten vergessen einzuplanen. Software braucht Hosting, Monitoring, Sicherheitsupdates und jemanden, den man anrufen kann, wenn montags um 8 Uhr etwas kaputt ist. Entscheiden Sie vor dem Launch, wer das macht und was es kostet.

Wenn Sie die interne Sicht darauf wollen, wie wir diese Phasen strukturieren, beschreibt unsere Seite zur Entwicklung von Webanwendungen den Prozess genauer.

Was in den Vertrag gehört

Nicht-technische Auftraggeber lesen meist Preis und Termin und überfliegen den Rest. Die Klauseln unten sind die, die zählen, wenn etwas schiefgeht.

Der Umfang muss in einer Form festgehalten sein, die beide Seiten prüfen können. Ein Verweis auf "die Spezifikation vom Datum X" ist in Ordnung, solange dieses Dokument tatsächlich existiert und beide Seiten es gelesen haben. "Eine Webanwendung für die Auftragsverwaltung" ist ein Thema, kein Umfang.

Abnahmekriterien definieren, wann ein Lieferergebnis als fertig gilt. Ohne sie wird jede Meinungsverschiedenheit über Qualität zur Verhandlung. Gute Kriterien sind prüfbar: "Ein Nutzer mit der Rolle Freigeber kann eine Bestellung freigeben, und der Lieferant erhält die Bestätigungsmail innerhalb einer Minute" schlägt "der Freigabeworkflow funktioniert".

Der Umgang mit Änderungen beschreibt, was passiert, wenn Sie etwas wollen, das nicht im Umfang ist. Das wird passieren, und das ist normal. Der Vertrag sollte regeln, wie Änderungen geschätzt werden, wer sie freigibt und wie sie den Zeitplan beeinflussen. Festpreisverträge ohne Änderungsklausel enden meist entweder mit einer aufgeblähten Schlussrechnung oder mit einem Anbieter, der stillschweigend Abstriche macht.

Das Eigentum am Quellcode ist die Klausel, die am häufigsten falsch läuft. Sie bezahlen für die Software, also sollten Sie den Code besitzen oder mindestens eine uneingeschränkte, unbefristete Lizenz haben, ihn zu nutzen, zu verändern und von anderen verändern zu lassen. Sie sollten außerdem während des Projekts Zugang zum Repository haben, nicht nur ein Übergabearchiv am Ende. Fragen Sie ausdrücklich nach Drittkomponenten und Lizenzen, die der Anbieter einsetzen will; Open-Source-Komponenten sind Standard, aber Sie wollen wissen, welche, und unter welcher Lizenz.

Datenschutz ist nicht optional, wenn die Anwendung personenbezogene Daten verarbeitet, was fast jede Anwendung tut. Der Vertrag braucht eine Vereinbarung zur Auftragsverarbeitung nach Art. 28 DSGVO, wenn der Anbieter Produktionsdaten hostet oder darauf zugreift, eine Angabe, wo Daten gespeichert werden, und Klarheit darüber, wer Verantwortlicher und wer Auftragsverarbeiter ist.

Wartung und Gewährleistung sollten getrennt sein. Gewährleistung deckt Mängel am Gelieferten ab, für einen definierten Zeitraum, ohne Zusatzkosten. Wartung deckt ab, das System danach gesund zu halten: Sicherheitsupdates, Aktualisierung von Abhängigkeiten, kleine Änderungen. Vereinbaren Sie Reaktionszeiten für die Wartungsphase und definieren Sie, was "kritisch" bedeutet.

Exit-Regelungen sind unangenehm zu verhandeln und unverzichtbar. Wenn die Zusammenarbeit endet, was erhalten Sie, in welchem Format und in welchem Zeitraum? Code, Datenbankdumps, Dokumentation, Zugangsdaten, Domain- und Hosting-Konten auf Ihren Namen. Eine Anwendung, die Sie nicht zu einem anderen Team umziehen können, ist eine Belastung.

Wo ausgelagerte Projekte scheitern

Die Fehlschläge, die wir sehen, wenn wir gebeten werden, ein Problemprojekt zu prüfen, folgen einer kleinen Zahl von Mustern.

Das häufigste ist eine fehlende oder vage Spezifikation. Beide Seiten glaubten, sich einig zu sein, stellten auf halbem Weg fest, dass sie es nicht waren, und streiten jetzt darüber, wer die Differenz bezahlt. Discovery und schriftliche Abnahmekriterien existieren genau dafür.

Das zweite ist Kommunikation, die nach der Verkaufsphase abbricht. Die Person, die das Projekt verkauft hat, verschwindet, und der Auftraggeber hört einmal im Monat vom Team. Bestehen Sie auf einem namentlich benannten technischen Ansprechpartner, regelmäßigen Demos und Zugang zur Testumgebung. Wenn Sie keinen Fortschritt sehen können, gehen Sie davon aus, dass es weniger gibt als berichtet.

Das dritte sind versteckte Kosten. Hosting, Lizenzen für Drittdienste, die Wartungspauschale, die Integration, die "einfach sein sollte", das mobile Layout, das niemand bepreist hat. Ein seriöser Partner listet diese vorab auf und sagt Ihnen, welche davon Schätzungen sind. Wenn ein Angebot weit unter den anderen liegt, fragen Sie, was es auslässt, statt anzunehmen, Sie hätten ein Schnäppchen gefunden.

Das vierte ist Qualität, die Sie erst sehen, wenn es zu spät ist. Eine Anwendung kann fertig aussehen und trotzdem keine automatisierten Tests, keine Dokumentation und eine Struktur haben, die nur ihr ursprünglicher Autor versteht. Sie müssen den Code nicht lesen können, um sich zu schützen: Schreiben Sie die Anforderung nach Tests und Dokumentation in den Vertrag, verlangen Sie vor der Endabnahme einen Rundgang durch die Codebasis, und erwägen Sie, einen unabhängigen Prüfer darauf schauen zu lassen. Das kostet ein paar Tage und kann Ihnen die Kosten eines Neubaus ersparen.

Preismodelle verdienen hier ebenfalls eine Erwähnung, denn die Wahl zwischen Festpreis, Time and Materials und Retainer verändert, wer welches Risiko trägt. Wir haben beschrieben, wie sich diese Modelle für EU-Auftraggeber gegeneinander abwägen, wenn Sie tiefer einsteigen wollen.

Eine kurze Checkliste vor der Unterschrift

Bevor Sie sich festlegen, sollten Sie jede dieser Fragen mit Ja beantworten können. Sie haben eine schriftliche Spezifikation mit Abnahmekriterien. Sie kennen die Phasen und wissen, was Sie am Ende jeder Phase sehen werden. Sie besitzen den Code und haben Zugang zum Repository. Es gibt eine Vereinbarung zur Auftragsverarbeitung. Gewährleistung und Wartung sind getrennt definiert, mit Reaktionszeiten. Sie wissen, was die Anwendung im ersten Jahr in Bau und Betrieb kostet. Sie wissen, was passiert, wenn eine Seite aussteigt.

Wenn eine Antwort Nein lautet, ist das das Gespräch, das Sie vor dem Kickoff führen sollten, nicht danach.

Wie Wolf-Tech mit Auftraggebern arbeitet

Wir bauen individuelle Webanwendungen für Unternehmen, die meist kein eigenes Entwicklungsteam haben, die meisten unserer Kunden sind also genau die Menschen, für die dieser Artikel geschrieben ist. Jedes Projekt beginnt mit einer bezahlten Discovery-Phase, liefert alle zwei Wochen funktionierende Software in eine Umgebung, in der Sie sich anmelden können, und endet mit Code in einem Repository, das Ihnen gehört. Wenn Sie eine Webanwendung beauftragen wollen und eine zweite Meinung zu Ihrem Briefing, Ihrer Shortlist oder einem erhaltenen Angebot möchten, schreiben Sie an hello@wolf-tech.io oder besuchen Sie wolf-tech.io. Ein kurzes Gespräch reicht meist, um zu erkennen, ob ein Projekt gut aufgesetzt ist.