Webentwicklungs-Angebot anfragen: Checkliste für neue Funktionen

Für ein Webentwicklungs-Angebot genügt eine kurze Beschreibung der gewünschten Funktion – die Details könne der Entwickler später klären. Das klingt effizient, führt aber häufig zu Angeboten, die auf unterschiedlichen Annahmen beruhen und deshalb kaum vergleichbar sind. Für eine belastbare Einschätzung brauchst du kein technisches Lastenheft. Du musst den gewünschten Ablauf so beschreiben, dass Umfang, Abhängigkeiten und offene Entscheidungen erkennbar werden.

Als durchgängiges Beispiel dient hier ein Formular, das Anfragen anhand der Postleitzahl an den passenden Standort weiterleitet. Die Grundidee passt in einen Satz. Für ein Angebot fehlen trotzdem wesentliche Informationen: Welche Postleitzahl gehört zu welchem Standort? Was passiert bei unbekannten Werten? Wer pflegt die Zuordnung? Soll die Anfrage nur per E-Mail versendet oder zusätzlich in einem bestehenden System gespeichert werden?

Beginne mit dem geschäftlichen Ergebnis

Eine Angebotsanfrage sollte zuerst erklären, welches Ergebnis die Funktion für dein Unternehmen oder die Nutzer erreichen soll. Beschreibe dabei noch keine technische Lösung. Sonst legst du möglicherweise eine Umsetzung fest, obwohl eigentlich nur das Ziel feststeht.

Für das Beispielformular wäre das Ergebnis: Eine eingehende Anfrage soll ohne manuelle Vorsortierung beim zuständigen Standort ankommen. Damit ist klar, dass die automatische Zuordnung zum Kern der Aufgabe gehört. Ob sie über eine Tabelle, eine Schnittstelle oder Einstellungen im vorhandenen System umgesetzt wird, kann die technische Prüfung ergeben.

Beantworte für den Einstieg drei Fragen:

• Welches konkrete Problem besteht im heutigen Ablauf?
• Was soll nach der Umsetzung anders funktionieren?
• Woran erkennst du im Alltag, dass die Funktion ihren Zweck erfüllt?

Formulierungen wie moderner Prozess, bessere Nutzererfahrung oder mehr Automatisierung reichen dafür nicht. Ein prüfbares Ergebnis ist genauer: Anfragen werden anhand einer gepflegten Zuordnung automatisch verteilt und bei fehlender Zuordnung an eine zentrale Stelle geschickt.

Beschreibe einen vollständigen Normalfall

Als Nächstes braucht der Entwickler den üblichen Ablauf vom Auslöser bis zum Ergebnis. Dieser Normalfall wird auch als Happy Path bezeichnet: der Weg, auf dem alle Eingaben gültig sind und keine Ausnahme eintritt.

Schreibe den Ablauf aus Sicht der beteiligten Person auf. Für das Beispiel könnte er so aussehen:

1. Ein Interessent öffnet das Anfrageformular.
2. Er trägt Kontaktdaten, Postleitzahl und Anliegen ein.
3. Das System ermittelt anhand der Postleitzahl den zuständigen Standort.
4. Die Anfrage wird an diesen Standort übermittelt.
5. Der Interessent erhält eine Bestätigung.
6. Der Standort kann erkennen, über welches Formular die Anfrage eingegangen ist.

Diese Darstellung ist wertvoller als eine Liste gewünschter Felder. Sie zeigt, welche Schritte zusammengehören und an welchen Stellen Entscheidungen oder technische Übergaben stattfinden. Zugleich bleibt sie offen genug, damit die Umsetzung fachlich geplant werden kann.

Lege Nutzer und Berechtigungen fest

Eine Funktion wird schnell aufwendiger, wenn mehrere Personengruppen unterschiedliche Dinge sehen oder bearbeiten dürfen. Deshalb sollte die Anfrage benennen, wer die Funktion nutzt und welche Rechte jeweils benötigt werden.

Beim Formular ist der öffentliche Nutzer nur eine Rolle. Zusätzlich könnte es Mitarbeitende geben, die Standortdaten verwalten. Dann sind weitere Fragen relevant:

• Dürfen alle Mitarbeitenden sämtliche Zuordnungen bearbeiten?
• Hat jeder Standort nur Zugriff auf seine eigenen Daten?
• Wer darf neue Standorte anlegen oder Empfänger ändern?
• Wird ein vorhandener Benutzerzugang genutzt oder ist eine neue Anmeldung nötig?

Falls die Verwaltung zunächst gar nicht Bestandteil des Auftrags sein soll, gehört auch das in die Anfrage. Eine manuell durch den Entwickler gepflegte Zuordnung kann für einen ersten, stabilen Datenbestand ausreichen. Bei häufigen Änderungen wäre sie dagegen ein absehbares Hindernis. Entscheidend ist, dass das Angebot von derselben Annahme ausgeht wie du.

Kläre Datenquelle und Datenpflege

Viele kleine Webfunktionen wirken an der Oberfläche überschaubar, hängen aber von Daten ab, deren Herkunft ungeklärt ist. Die Aufwandsschätzung verändert sich erheblich, je nachdem, ob Daten bereits strukturiert vorliegen, aus einem anderen System abgerufen oder erst aufbereitet werden müssen.

Notiere deshalb zu jedem benötigten Datenbestand:

• Wo liegen die Daten heute?
• In welchem Format sind sie verfügbar?
• Wer ist fachlich für ihre Richtigkeit verantwortlich?
• Wie oft ändern sie sich?
• Wer soll Änderungen künftig eintragen?

Für die Standortzuordnung könnte eine gepflegte Tabelle existieren. Dann sollte eine Beispieldatei zur Angebotsanfrage gehören. Liegen die Informationen nur in E-Mails oder im Wissen einzelner Mitarbeitender, ist die fachliche Aufbereitung eine eigene Aufgabe. Der Entwickler kann eine Regel technisch umsetzen, aber er kann nicht erraten, welcher Standort für eine bestimmte Region zuständig sein soll. Hellsehen ist weiterhin kein verlässliches Webframework.

Formuliere Regeln und Ausnahmen

Der Normalfall beschreibt die Funktion, die Ausnahmen bestimmen häufig ihren tatsächlichen Umfang. Du musst nicht jede theoretische Fehlersituation vorwegnehmen. Die fachlich absehbaren Fälle sollten jedoch vor dem Angebot benannt werden.

Beim Beispiel sind unter anderem diese Fragen zu klären:

• Was geschieht bei einer ungültigen oder unvollständigen Postleitzahl?
• Was passiert, wenn keine Zuordnung vorhanden ist?
• Kann eine Postleitzahl mehreren Standorten zugeordnet sein?
• Wie wird mit vorübergehend geschlossenen Standorten umgegangen?
• Wohin geht die Anfrage, wenn ein Empfänger technisch nicht erreichbar ist?
• Darf der Nutzer seinen Standort selbst auswählen oder ist die Zuordnung verbindlich?

Du kannst offene Punkte ausdrücklich als offene Entscheidung markieren. Das ist besser als eine stillschweigende Annahme. Bitte im Angebot darum, solche Punkte entweder als Voraussetzung, Option oder ausgeschlossenen Leistungsbestandteil zu kennzeichnen.

Benenne angebundene Systeme konkret

Sobald Daten die Website verlassen oder aus einem anderen System kommen, entsteht eine Schnittstelle. Eine Schnittstelle ist ein festgelegter technischer Übergabepunkt zwischen zwei Systemen. Ihr Aufwand hängt nicht allein davon ab, dass beide Systeme grundsätzlich Daten austauschen können.

Nenne bei einer geplanten Anbindung den Anbieter und das verwendete Produkt. Ergänze, soweit bekannt:

• ob bereits ein passender Zugang besteht,
• ob eine technische Dokumentation verfügbar ist,
• welche Daten übertragen werden sollen,
• in welche Richtung die Übertragung läuft,
• wie mit fehlgeschlagenen Übertragungen umgegangen werden soll,
• wer aufseiten des angebundenen Systems Fragen beantworten kann.

Die Aussage Das Formular soll an unser CRM angebunden werden lässt zu viel offen. Gemeint sein könnte ein einfacher Eintrag eines Kontakts. Ebenso denkbar sind Dublettenprüfung, Zuordnung zu Vertriebsgebieten, Dateiübertragung, Einwilligungsnachweise und Statusrückmeldungen. Diese Varianten sehen im Formular ähnlich aus, sind technisch jedoch verschiedene Aufgaben.

Falls du noch nicht entschieden hast, ob eine Anbindung nötig ist, bitte um getrennte Positionen: eine Grundversion ohne Integration und eine Erweiterung mit Integration. So bleibt die Budgetentscheidung sichtbar, statt in einer Gesamtsumme zu verschwinden.

Trenne den ersten Umfang von späteren Ideen

Eine Angebotsanfrage wird nicht besser, indem jede denkbare Erweiterung zum Pflichtbestandteil erklärt wird. Sie wird besser, wenn klar zwischen dem jetzt benötigten Umfang und möglichen späteren Ausbaustufen unterschieden wird.

Für das Anfrageformular könnte die erste Version nur die Zuordnung, Weiterleitung und Bestätigung enthalten. Ein internes Auswertungs-Dashboard, automatische Erinnerungen oder mehrsprachige Vorlagen wären mögliche Erweiterungen. Sie dürfen erwähnt werden, sollten aber als spätere Ideen gekennzeichnet sein.

Diese Trennung hilft dem Entwickler bei zwei Entscheidungen: Die erste Version kann passend abgegrenzt werden, und ihre Umsetzung verbaut offensichtliche Erweiterungen nicht unnötig. Daraus folgt allerdings keine Pflicht, jede hypothetische Zukunft schon technisch vorzubereiten. Eine Option, die vielleicht irgendwann gebraucht wird, sollte nicht ungefragt das aktuelle Budget übernehmen.

Ordne Inhalte und Gestaltung zu

Bei Webfunktionen entstehen Texte, E-Mails, Hinweise und Zustände. Häufig bleibt vor dem Angebot offen, wer diese Inhalte liefert und ob vorhandene Gestaltungsvorgaben ausreichen.

Halte fest, wer verantwortlich ist für:

• Beschriftungen und Hilfetexte im Formular,
• Fehler- und Bestätigungsmeldungen,
• automatisch versendete E-Mails,
• rechtlich zu prüfende Hinweise und Einwilligungstexte,
• Übersetzungen,
• Grafiken oder andere Medien.

Wenn die neue Funktion in eine bestehende Website eingebaut wird, sende die URL der betroffenen Seite und vorhandene Gestaltungsvorgaben mit. Ein Entwurf oder eine Skizze kann helfen, sollte aber als fachliche Vorstellung oder verbindliche Designvorgabe gekennzeichnet sein. Andernfalls kalkuliert ein Anbieter die Gestaltung mit, während ein anderer nur die technische Umsetzung annimmt.

Mach Datenschutz und sensible Daten sichtbar

Du musst die rechtliche Bewertung einer Funktion nicht an den Entwickler delegieren. Für das Angebot muss aber erkennbar sein, welche personenbezogenen oder vertraulichen Daten verarbeitet werden und wohin sie gelangen.

Liste die betroffenen Datenarten und Empfänger auf. Beim Formular können das Name, Kontaktdaten, Standortangabe und der frei eingegebene Nachrichtentext sein. Gerade Freitextfelder sind relevant, weil Nutzer dort Inhalte eintragen können, die du nicht im Voraus kennst.

Kläre außerdem, ob Daten nur weitergeleitet, zusätzlich in der Website gespeichert oder an einen externen Dienst übertragen werden. Wenn dein Datenschutzbeauftragter oder eine andere fachlich zuständige Stelle Vorgaben machen muss, sollte diese Prüfung als Abhängigkeit im Ablauf stehen. So wird sie weder stillschweigend im Entwicklungsangebot vorausgesetzt noch erst kurz vor Veröffentlichung entdeckt.

Definiere die Abnahme mit beobachtbaren Kriterien

Abnahmekriterien beschreiben, welche nachprüfbaren Bedingungen die gelieferte Funktion erfüllen muss. Sie übersetzen das gewünschte Ergebnis in konkrete Fälle und reduzieren Diskussionen darüber, ob eine Umsetzung vollständig ist.

Gute Kriterien für das Beispiel wären:

• Bei einer bekannten Postleitzahl wird die Anfrage an den zugeordneten Standort gesendet.
• Bei einer unbekannten Postleitzahl geht die Anfrage an die festgelegte zentrale Adresse.
• Pflichtfelder werden vor dem Absenden geprüft und verständlich markiert.
• Nach erfolgreicher Übermittlung sieht der Nutzer eine Bestätigung.
• Bei einem technischen Fehler wird keine erfolgreiche Übermittlung behauptet.
• Berechtigte Mitarbeitende können die Zuordnung auf dem vereinbarten Weg ändern.

Vermeide Kriterien wie intuitiv bedienbar oder funktioniert zuverlässig, wenn sie allein stehen. Beide Ziele sind sinnvoll, aber ohne konkreten Prüfmaßstab unterschiedlich auslegbar. Beschreibe stattdessen die wichtigsten Aufgaben, erwarteten Ergebnisse und relevanten Geräte oder Browser, soweit sie für dein Projekt festgelegt sind.

Stelle vorhandenes Material geordnet bereit

Die Angebotsphase wird unnötig zäh, wenn Informationen über E-Mails, Chatnachrichten und Besprechungsnotizen verteilt sind. Eine kurze zentrale Beschreibung mit verlinkten Anlagen reicht meistens aus. Sie sollte erkennen lassen, welche Dokumente aktuell und welche nur Beispiele sind.

Je nach Funktion können folgende Unterlagen nützlich sein:

• URL und Screenshots des heutigen Ablaufs,
• Beispieldaten ohne unnötige personenbezogene Angaben,
• Skizzen oder Entwürfe,
• Dokumentation angebundener Systeme,
• vorhandene Rollen- und Rechtebeschreibungen,
• Gestaltungsvorgaben,
• bekannte technische oder organisatorische Einschränkungen.

Produktive Zugangsdaten gehören nicht ungeschützt in die Angebotsanfrage. Für eine erste Einschätzung genügt meist die Information, welche Systeme und Zugänge vorhanden sind. Falls eine technische Vorprüfung nötig ist, kann der sichere Zugang getrennt vereinbart werden.

Nutze diese kompakte Checkliste für deine Anfrage

Vor dem Versand kannst du prüfen, ob deine Beschreibung die folgenden Punkte beantwortet. Ungeklärte Fragen dürfen offenbleiben, sollten aber ausdrücklich als offen markiert sein.

1. Ziel: Welches konkrete Ergebnis soll die Funktion liefern?
2. Ausgangslage: Wie läuft die Aufgabe heute ab und wo entsteht das Problem?
3. Normalfall: Welche Schritte durchläuft ein Nutzer vom Start bis zum Ergebnis?
4. Nutzer: Welche Personengruppen verwenden oder verwalten die Funktion?
5. Rechte: Wer darf welche Daten sehen, anlegen oder ändern?
6. Daten: Woher kommen die benötigten Informationen und wer pflegt sie?
7. Regeln: Nach welchen fachlichen Vorgaben trifft die Funktion Entscheidungen?
8. Ausnahmen: Was soll bei fehlenden Daten, Fehlern oder Sonderfällen passieren?
9. Schnittstellen: Welche vorhandenen Systeme sollen Daten senden oder empfangen?
10. Inhalte: Wer liefert Texte, E-Mails, Übersetzungen und rechtlich zu prüfende Hinweise?
11. Umfang: Was gehört in die erste Version und was ausdrücklich noch nicht?
12. Abnahme: Mit welchen beobachtbaren Fällen wird die Funktion geprüft?
13. Rahmen: Gibt es einen Zieltermin, feste Abhängigkeiten oder eine Budgetgrenze?
14. Material: Welche Beispiele, Skizzen und Dokumentationen liegen bereits vor?

Prüfe das Angebot auf Annahmen statt nur auf den Preis

Selbst eine gute Anfrage beseitigt nicht jede Unsicherheit. Ein brauchbares Angebot macht deshalb sichtbar, von welchen Voraussetzungen die Kalkulation ausgeht. Prüfe, ob die beschriebenen Leistungen zu deinem Normalfall, den Ausnahmen und den vereinbarten Grenzen passen.

Achte insbesondere auf folgende Punkte:

• Sind Konzeption, Gestaltung, Entwicklung und Tests eindeutig zugeordnet?
• Ist erkennbar, welche Inhalte und Daten du liefern musst?
• Werden Schnittstellen und externe Systeme konkret benannt?
• Sind offene Entscheidungen als Annahmen oder optionale Positionen aufgeführt?
• Ist beschrieben, was nicht zum angebotenen Umfang gehört?
• Ist geregelt, wie zusätzliche Wünsche nach der Beauftragung behandelt werden?
• Passen die Abnahmekriterien zu dem Ergebnis, das du benötigst?

Vergleiche Angebote nicht nur anhand der Endsumme. Ein niedrigerer Preis kann auf einem kleineren Leistungsumfang, weniger berücksichtigten Ausnahmen oder zusätzlichen Eigenleistungen beruhen. Umgekehrt ist eine umfangreiche Position nicht automatisch nötig, wenn sie eine spätere Ausbaustufe vorwegnimmt, die du aktuell nicht brauchst.

Eine gute Anfrage löst fachliche Fragen vor der Kalkulation

Du musst eine neue Webfunktion nicht selbst technisch planen, bevor du ein Angebot anfragst. Deine Aufgabe ist eine andere: Beschreibe Ziel, Ablauf, Beteiligte, Daten, Regeln und Grenzen so konkret, dass technische Annahmen erkennbar werden. Offene Punkte sind dabei kein Mangel, solange sie benannt und im Angebot behandelt werden.

Die beste Checkliste produziert daher kein möglichst langes Dokument. Sie sorgt dafür, dass alle Beteiligten über dieselbe Funktion sprechen. Erst dann lassen sich Aufwand, Optionen und Preise sinnvoll einordnen – und aus einem knappen Wunsch wird eine beauftragbare Aufgabe.