Was tun, wenn der Kunde seine Bedürfnisse nicht definieren kann?

Der Kunde muss die fertige Lösung nicht kennen

Der Kunde beauftragt unter anderem deshalb einen Spezialisten, weil er selbst nicht weiß, wie er sein Problem am besten lösen soll. Der Inhaber des Unternehmens kann feststellen, dass die Website keine Anfragen bringt, die Mitarbeiter Zeit mit dem manuellen Übertragen von Daten verlieren oder die Marke weniger professionell wirkt als die Konkurrenz. Er muss jedoch nicht wissen, ob er ein Redesign des Formulars, eine neue Informationsarchitektur, eine CRM-Integration, ein Rebranding der Marke oder eine ganz andere Lösung benötigt.

Die Erwartung, dass der Kunde eine vollständige und korrekte Spezifikation vorbereitet, ist manchmal unrealistisch. Es ist ein bisschen so, als würde ein Mechaniker erwarten, dass der Fahrer vor dem Besuch den Fehler selbst diagnostiziert und die auszutauschenden Teile benennt. Der Kunde sollte in der Lage sein, die Symptome, den Kontext und das erwartete Ergebnis zu beschreiben. Die Aufgabe des Spezialisten besteht darin, ihm zu helfen, von diesen Informationen zur richtigen Lösung zu gelangen.

Das bedeutet jedoch nicht, dass der Freelancer das gesamte Projekt auf Grundlage eines einzigen Satzes allein erfinden soll. Die Ermittlung der Bedürfnisse erfordert Zusammenarbeit. Der Kunde bringt Wissen über das Unternehmen, die Zielgruppe, Einschränkungen und frühere Erfahrungen ein. Der Auftragnehmer bringt Branchenwissen, die Fähigkeit, Fragen zu stellen, sowie die Einschätzung der Umsetzbarkeit der vorgeschlagenen Lösungen ein.

Der Kunde muss nicht wissen, wie man die Lösung baut. Er sollte jedoch an der Festlegung beteiligt sein, welches Problem wir lösen und woran wir erkennen, dass das Projekt erfolgreich war.

Briefstreak

Warum kann der Kunde seine Bedürfnisse nicht bestimmen?

Unklare Anforderungen resultieren nicht immer aus mangelnder Vorbereitung. Manchmal befindet sich ein Projekt einfach in einem sehr frühen Stadium. Der Kunde erkennt das Problem, hat es aber noch nicht analysiert. In anderen Fällen kennt er das gewünschte Ergebnis, versteht aber weder die verfügbaren Möglichkeiten noch die technischen Einschränkungen.

Er kennt das Problem, aber nicht die möglichen Lösungen

Der Kunde weiß, dass zu viele Personen den Kauf abbrechen, aber er kann die Ursache nicht benennen. Er kann annehmen, dass er einen neuen Onlineshop braucht, obwohl das Problem ein kompliziertes Lieferformular ist. Er kann nach einer mobilen App fragen, obwohl seinen Zielgruppen ein gut funktionierendes Web-Panel ausreichen würde.

Es ist natürlich, dass der Kunde den Bedarf durch die Brille einer Lösung beschreibt, die er kennt. Deine Aufgabe ist es nicht, seinen Vorschlag automatisch abzulehnen, sondern zu prüfen, warum er gerade daran gedacht hat und welchen Effekt er damit erreichen möchte.

Im Unternehmen gibt es nicht nur eine Version der Bedürfnisse

Die Person, die die Dienstleistung bestellt, kann nur eine Sichtweise vertreten. Der Eigentümer möchte den Umsatz steigern, das Marketing möchte Inhalte leicht veröffentlichen, die Supportabteilung erwartet weniger wiederkehrende Fragen, und die Nutzer brauchen einen einfacheren Prozess. All diese Bedürfnisse können berechtigt sein, aber sie sind nicht immer miteinander vereinbar.

Wenn das Projekt mehrere Stakeholder hat, reicht es nicht aus, eine Person zu fragen, was sie braucht. Es muss geklärt werden, wer die Lösung nutzen wird, wer sie freigibt, wer das Projekt finanziert und wessen tägliche Arbeit sich ändern wird.

Der Kunde kann Prioritäten nicht von Ideen trennen

Während des Gesprächs kann der Kunde mehrere Dutzend Funktionen, Inspirationen und lose Konzepte nennen. Das bedeutet nicht, dass alle Anforderungen sind. Ein Teil ist der Versuch, sich das Projekt vorzustellen, ein Teil ist ein Zusatz für die Zukunft, und ein Teil ist eine Idee, die von der Konkurrenz gehört wurde.

Wenn alles als gleich wichtig behandelt wird, wird der Umfang schnell zu groß und zu kostspielig. Deshalb müssen die Bedürfnisse nach ihrer Bedeutung, ihrem Einfluss auf das Ziel und den Konsequenzen eines Verzichts auf das jeweilige Element geordnet werden.

Der Kunde befürchtet, das Budget anzugeben

Einige Kunden vermeiden konkrete Antworten, weil sie glauben, dass der Auftragnehmer jede Information nutzen wird, um den Preis zu erhöhen. Sie wollen weder das Budget noch den erwarteten Umfang noch die Wichtigkeit einzelner Elemente nennen. Sie hoffen, zunächst einen vollständigen Vorschlag zu erhalten und erst dann zu entscheiden, was sie wirklich benötigen.

In einer solchen Situation ist es sinnvoll zu erklären, dass dieselben Ziele auf verschiedenen Ebenen erreicht werden können. Das Budget dient nicht dazu, den Preis automatisch festzulegen, sondern eine realistische Lösung auszuwählen. Ohne diese Information können Sie ein Angebot vorbereiten, das völlig ungeeignet für die Möglichkeiten des Kunden ist.

Der Kunde hat zuvor noch nie einen ähnlichen Service bestellt

Die Person, die die erste Webseite, die visuelle Identität, die Werbekampagne oder das IT-System bestellt, weiß möglicherweise nicht, welche Entscheidungen sie treffen muss. Sie kennt den branchenüblichen Prozess, die typischen Phasen oder die Faktoren, die den Preis beeinflussen, nicht.

Anstatt eine solche Anfrage als unprofessionell zu bewerten, muss man den Kunden durch den Prozess führen. Gute Fragen sollten ohne Fachwissen verständlich sein und sich vor allem auf das Unternehmen, die Nutzer, die Probleme sowie die erwarteten Ergebnisse beziehen.

Das Problem ist noch zu wenig erkannt.

Manchmal kennt keine der beiden Seiten zu Beginn die Antwort. Es ist nicht bekannt, warum Kunden das Formular abbrechen, welche Prozesse am meisten Zeit in Anspruch nehmen oder ob Nutzer die geplante Funktion benötigen. Die Antworten erfordern Datenanalyse, Gespräche mit Nutzern, ein Audit, einen Workshop oder die Erstellung eines Prototyps.

In einem solchen Projekt sollte man nicht so tun, als wäre der Umfang bekannt. Das erste Produkt der Zusammenarbeit sollte ein besseres Verständnis des Problems sein, und erst das zweite die eigentliche Lösung.

Trenne zuerst das Bedürfnis von der vorgeschlagenen Lösung

Eines der wichtigsten Elemente von Discovery ist die Unterscheidung zwischen dem, was der Kunde tatsächlich braucht, und dem, was er vorschlägt zu bauen. Der Satz „wir brauchen eine mobile Anwendung“ beschreibt eine Lösung. Er erklärt nicht, wer sie nutzen wird, in welcher Situation, welches Problem verschwinden soll oder warum die vorhandenen Werkzeuge nicht ausreichen.

Ähnlich verhält es sich mit der Bitte um ein neues Logo, ein Redesign der Website, eine Kampagne in den sozialen Medien oder die Automatisierung eines Prozesses. Jede dieser Ideen kann treffend sein, aber bevor mit der Umsetzung begonnen wird, muss der dahinterstehende Grund bekannt sein.

Beginne nicht mit der Frage: „Was sollen wir erstellen?“. Beginne mit der Frage: „Was soll sich nach Abschluss des Projekts ändern?“.

Briefstreak

Es ist hilfreich, die Antwort des Kunden umzuformulieren. Wenn er sagt, dass er eine neue Website möchte, kannst du zusammenfassen: „Ich verstehe, dass das Hauptproblem die geringe Anzahl an Anfragen von Geschäftskunden ist und das Ziel des Projekts darin besteht, die Anzahl wertvoller Kontakte zu erhöhen. Die neue Website ist derzeit eine erwogene Möglichkeit, dieses Ziel zu erreichen“. Ein solcher Satz lässt Raum dafür, zu prüfen, ob ein kompletter Umbau der gesamten Website tatsächlich notwendig ist.

Beginne mit der aktuellen Situation und nicht mit der Funktionsliste

Wenn der Kunde seine Bedürfnisse nicht definieren kann, hilft die Frage „Welche Funktionen soll das System haben?“ in der Regel nicht. Die Antwort wird sehr allgemein sein oder auf zufälligen Inspirationen basieren. Es ist einfacher, darüber zu sprechen, was derzeit passiert.

• Wie wird dieser Prozess derzeit durchgeführt?
• Wer ist daran beteiligt?
• Was löst den gesamten Prozess aus?
• An welcher Stelle treten die meisten Probleme auf?
• Was nimmt am meisten Zeit in Anspruch?
• Welche Fehler wiederholen sich am häufigsten?
• Welche Werkzeuge nutzt der Kunde heute?
• Was funktioniert in der aktuellen Lösung gut und sollte beibehalten werden?
• Welche Umgehungslösungen verwenden die Mitarbeiter oder Benutzer?
• Was passiert, wenn das Problem nicht gelöst wird?

Die Beschreibung eines realen Prozesses liefert deutlich mehr Informationen als eine abstrakte Liste von Erwartungen. Der Kunde erinnert sich vielleicht nicht daran, dass er einen Datenexport benötigt, aber wenn er seine Arbeit beschreibt, erwähnt er, dass er jeden Freitag die Ergebnisse manuell in eine Tabelle überträgt. Gerade in solchen Details verbergen sich oft die wichtigsten Anforderungen.

Bestimme, was der Kunde zu erreichen versucht

Das Projekt sollte zu einer bestimmten Veränderung führen. Allein die Erstellung einer Website, eines Films, einer Identität oder einer Anwendung ist die Lieferung eines Produkts, erklärt aber nicht seinen Zweck. Um den Umfang gut festzulegen, muss man verstehen, wofür die Lösung dem Kunden benötigt wird.

Hilfreich ist es, in Kategorien der Aufgabe zu denken, die der Kunde oder sein Empfänger zu erledigen versucht. Der Nutzer braucht kein Formular um des Formulars willen. Er möchte schnell ein Angebot erhalten. Das Unternehmen braucht kein Dashboard nur deshalb, weil es professionell aussieht. Es möchte Umsatzrückgänge früher erkennen und treffendere Entscheidungen treffen.

• Warum wird dieses Projekt gerade jetzt benötigt?
• Welches Problem soll gelöst werden?
• Wer spürt dieses Problem am stärksten?
• Wie gehen die Nutzer derzeit damit um?
• Was sollte einfacher, schneller oder günstiger werden?
• Welche Entscheidung oder Handlung soll die Lösung unterstützen?
• Was wird nach der Umsetzung möglich sein, was heute nicht möglich ist?
• Welche Folgen hat es, die aktuelle Situation unverändert zu lassen?

Definiere das Ergebnis, nicht nur die zu liefernden Materialien

Das Projektergebnis sollte sowohl das umfassen, was der Auftragnehmer liefert, als auch die Veränderung, die der Kunde erwartet. Das Material kann eine neue Website sein. Das erwartete Ergebnis ist ein leichteres Auffinden von Informationen und ein Anstieg der Anzahl wertvoller Anfragen. Das Material kann Automatisierung sein. Das Ergebnis ist die Verkürzung des Prozesses von zwei Stunden auf mehrere Minuten.

Nicht jedes Ergebnis kann garantiert werden. Ein Freelancer, der einen Shop gestaltet, hat keine vollständige Kontrolle über die Anzahl der Verkäufe, da auch das Angebot, der Traffic, die Preise und die Marketingmaßnahmen darauf Einfluss nehmen. Dennoch kann man weiterhin Kennzahlen definieren, auf die das Projekt einwirken soll, sowie Bedingungen, mit denen sich seine Qualität bewerten lässt.

• Woran erkennt der Kunde, dass das Projekt erfolgreich war?
• Welches Verhalten der Nutzer sollte sich ändern?
• Welcher Prozess sollte kürzer dauern?
• Welche Fehler sollten seltener auftreten?
• Welche Informationen sollten leichter zugänglich werden?
• Welches Mindestresultat rechtfertigt die Umsetzung des Projekts?
• Wann und auf welche Weise wird das Ergebnis bewertet?

Frage nach konkreten Situationen aus der Vergangenheit

Fragen über die Zukunft führen oft zu Aussagen und Wünschen. Ein Kunde kann sagen, dass das System „intuitiv“, „modern“, „skalierbar“ und „einfach“ sein sollte. Jeder versteht diese Wörter anders. Viel nützlicher sind Fragen nach konkreten Ereignissen.

• Wann ist dieses Problem zuletzt aufgetreten?
• Was genau ist damals passiert?
• Wer hat versucht, es zu lösen?
• Wie lange hat das gedauert?
• Welche Werkzeuge wurden verwendet?
• Was war am frustrierendsten?
• Wie ist diese Situation ausgegangen?
• Tritt ein ähnliches Problem regelmäßig auf?

Ein konkretes Beispiel ermöglicht es, den Kontext, die Reihenfolge der Aktivitäten, die Beteiligten und die Einschränkungen zu erkennen. Oft zeigt es auch den Unterschied zwischen dem, was das Unternehmen als seinen offiziellen Prozess ansieht, und dem, wie die Arbeit in der Praxis aussieht.

Frage nicht nur, was der Kunde will

Eine direkte Frage nach den Erwartungen ist notwendig, darf aber nicht die einzige Methode sein. Menschen lassen Tätigkeiten aus, die ihnen selbstverständlich erscheinen, erinnern sich nicht an alle Ausnahmen oder schlagen Lösungen auf der Grundlage begrenzten Wissens vor.

Je nach Art des Projekts lohnt es sich, das Gespräch durch die Analyse vorhandener Materialien, Daten, Formulare, Verfahren, Kundennachrichten, Gesprächsaufzeichnungen, Website-Statistiken oder verwendeter Tools zu ergänzen. Bei der Gestaltung von Prozessen kann auch die Beobachtung der tatsächlichen Arbeit der Nutzer hilfreich sein.

Der Kunde kann sagen, dass sein Mitarbeiter die Aufgabe auf einfache Weise ausführt. Erst die Beobachtung wird offenbaren, dass er zwischen den Schritten eine private Tabelle verwendet, Daten aus Nachrichten kopiert und einige Ausnahmen manuell überprüft. Diese Handlungen können für das Projekt von entscheidender Bedeutung sein, obwohl sie in der ursprünglichen Beschreibung nicht auftauchten.

Wie stellt man Fragen, um nützliche Antworten zu erhalten?

Stelle immer nur eine Frage auf einmal

Eine Frage, die mehrere Themen enthält, führt meist nur zu einer Antwort auf eines davon. Anstatt gleichzeitig nach Zielgruppe, Zweck, Budget, Funktionen und Termin zu fragen, teilen Sie das Gespräch in kürzere Abschnitte auf. So lassen sich Unklarheiten leichter erkennen und ergänzende Fragen stellen.

Vermeiden Sie Fachjargon

Der Kunde kann zustimmen, obwohl er die Frage zu Informationsarchitektur, Webhooks, Personas, Funnel, Key Visual oder Staging-Umgebung nicht versteht. Verwende eine Sprache, die Handlungen und Ergebnisse beschreibt. Technische Terminologie kann später eingeführt werden, wenn sie tatsächlich benötigt wird.

Bitte um Beispiele

Wenn der Kunde sagt, dass das Projekt professionell aussehen sollte, frage, welche konkreten Materialien er für professionell hält und was ihm daran genau gefällt. Wenn er eine einfache Bedienung erwartet, bitte um eine Beschreibung der Aufgabe, die der Nutzer ohne Hilfe ausführen soll.

Nach dem Grund fragen

Es geht nicht darum, die Frage „warum?“ mechanisch nach jeder Antwort zu wiederholen. Es lohnt sich jedoch, das Motiv hinter der Anforderung zu verstehen. Wenn der Kunde eine Anmeldung über soziale Medien möchte, frage, welches Problem dadurch gelöst werden soll. Vielleicht vergessen die Nutzer ihre Passwörter, die Registrierung dauert zu lange oder das Unternehmen möchte eine bestimmte Art von Daten gewinnen.

Fasse es mit eigenen Worten zusammen

Stelle nach dem wichtigeren Teil des Gesprächs dein eigenes Verständnis der Situation dar und bitte um Bestätigung. Wiederhole nicht einfach nur die Worte des Kunden. Versuche, die Zusammenhänge zwischen dem Problem, den Empfängern, dem Ziel und dem vorgeschlagenen Umfang zu ordnen.

Ich verstehe, dass das größte Problem nicht die Anzahl der Nachrichten selbst ist, sondern dass sie bei verschiedenen Personen landen und man nicht weiß, welche Anfragen bereits bearbeitet wurden. Priorität hat also ein gemeinsamer Ort zur Verwaltung der Anfragen, und automatische Antworten sind vorerst nur eine Ergänzung. Fasse ich das richtig zusammen?

Beispielhafte Zusammenfassung

Ermitteln Sie, wer das Lösung wirklich nutzt

Die Person, die die Dienstleistung kauft, ist nicht immer deren Nutzer. Der Eigentümer bestellt ein System für die Mitarbeiter, die Marketingabteilung eine Website für die Kunden und der Manager einen Bericht für den Vorstand. Jede dieser Gruppen kann andere Ziele, Einschränkungen und Wissensstände haben.

Wenn die Nutzer nicht an der Ermittlung der Bedürfnisse beteiligt sind, kann das Projekt den Erwartungen der entscheidenden Person entsprechen, aber die tägliche Arbeit erschweren. Nicht immer muss man große Untersuchungen durchführen. Manchmal reicht ein kurzes Gespräch mit einigen Personen, die den betreffenden Prozess ausführen.

• Wer wird die Lösung am häufigsten nutzen?
• Wer trifft die Kaufentscheidung?
• Wer wird das Ergebnis genehmigen?
• Wer wird Materialien und Wissen bereitstellen?
• Wessen Aufgaben werden sich nach der Einführung ändern?
• Wer wird die Lösung nach Abschluss des Projekts warten?
• Sind die Bedürfnisse der einzelnen Gruppen miteinander vereinbar?

Wandeln Sie allgemeine Bezeichnungen in Kriterien um

Wörter wie „modern”, „einfach”, „premium”, „schnell“, „flexibel“ oder „intuitiv“ sind noch keine Anforderungen. Sie sind eine Richtung, die noch genauer definiert werden muss.

Wenn die Seite schnell sein soll, lege fest, ob es um die technische Ladezeit, das leichte Finden von Informationen, einen kurzen Kaufprozess oder eine effiziente Inhaltsverwaltung geht. Wenn das System einfach sein soll, bestimme, welche Aufgaben der Benutzer ausführen soll und welche Fehler er derzeit macht.

• Was genau bedeutet diese Bezeichnung in diesem Projekt?
• Welches Beispiel erfüllt diese Erwartung?
• Welches Beispiel erfüllt sie eindeutig nicht?
• Wer wird dieses Element bewerten?
• Woran werden wir objektiv erkennen, dass die Anforderung erfüllt wurde?

Hilf dem Kunden, Prioritäten festzulegen

Wenn ein Gespräch gut verläuft, wächst die Liste der Bedürfnisse in der Regel. Das ist noch kein Problem. Ein Problem entsteht dann, wenn alle Elemente trotz begrenztem Budget und Termin als verpflichtend angesehen werden.

Prioritäten können festgelegt werden, indem man nach den Auswirkungen fragt, die entstehen, wenn auf ein bestimmtes Element verzichtet wird. Wenn ein Projekt ohne eine konkrete Funktion weiterhin das wichtigste Problem löst, ist sie wahrscheinlich in der ersten Version nicht unbedingt erforderlich.

• Was muss unbedingt in der ersten Version enthalten sein?
• Ohne was wird die Lösung den grundlegenden Zweck nicht erfüllen?
• Welche Elemente bringen den größten Nutzen?
• Was kann man zu Beginn manuell ausführen?
• Was kann in die nächste Phase verschoben werden?
• Welche Anforderungen ergeben sich aus Recht, Sicherheit oder Verträgen?
• Worauf würde der Kunde bei einem kleineren Budget zuerst verzichten?

Eine gute Methode ist die Einteilung in notwendige, wichtige, optionale und für später zurückgestellte Elemente. Allein das Zuweisen von Etiketten reicht nicht aus — jede Entscheidung sollte sich aus dem Projektziel und den verfügbaren Einschränkungen ergeben.

Zeige die Lösung an einem Beispiel, bevor du alles aufbaust

Einige Bedürfnisse lassen sich nicht allein durch Gespräche präzisieren. Erst nachdem der Kunde ein Beispiel gesehen hat, kann er erkennen, was fehlt, was überflüssig ist oder wie der Informationsfluss aussehen sollte.

Je nach Projekt können Skizzen, Mock-ups, Moodboards, Beispielinhalte, Prototypen, Muster, Prozesskarten oder kleine Demo-Versionen hilfreich sein. Ihr Zweck ist nicht, kostenlos Teile des Projekts auszuführen, sondern wichtige Annahmen vor einer kostspieligen Umsetzung schnell zu überprüfen.

Ein Prototyp sollte eine konkrete Frage beantworten. Er kann prüfen, ob der Benutzer das Formularlayout versteht, ob sich das System mit vorhandenen Daten verbinden lässt oder ob der vorgeschlagene Stil zur Positionierung der Marke passt. Es ist nicht notwendig, die gesamte Lösung zu entwerfen, um das wichtigste Risiko zu überprüfen.

Wann sollte Discovery kostenpflichtig sein?

Eine kurze Qualifizierung vor dem Angebot ist in der Regel Teil des Vertriebs. Du kannst kostenlos ein paar Fragen stellen, die Passung bewerten und den grundlegenden Umfang festlegen. Die Grenze ist überschritten, wenn der Kunde echte analytische Arbeit benötigt: ein Audit, eine Beratung mit mehreren Personen, Datenanalyse, Workshops, Prozessmapping oder die Ausarbeitung eines detaillierten Konzepts.

Eine solche Phase hat einen eigenständigen Wert. Nach ihrem Abschluss sollte der Kunde das Problem, die Prioritäten, Risiken und möglichen Lösungen besser verstehen – selbst wenn er die Umsetzung jemand anderem überträgt. Deshalb kann Discovery eine separate Dienstleistung sein und nicht nur eine kostenlose Ergänzung zur Kostenschätzung.

• Das Projekt ist komplex und umfasst viele Prozesse.
• Die Anforderungen mehrerer Stakeholder widersprechen sich.
• Es ist unklar, welche Lösung umsetzbar ist.
• Es muss das bestehende System oder die Dokumentation analysiert werden.
• Eine genaue Kostenschätzung erfordert die Ausarbeitung eines Konzepts.
• Das Projekt wird kostspielig sein, und falsche Annahmen können große Verluste verursachen.
• Der Kunde erwartet einen Workshop, ein Audit, Untersuchungen oder eine detaillierte Empfehlung.

Was kann im Rahmen eines bezahlten Discoverys entstehen?

• Beschreibung des Problems und des Projektziels.
• Karte des aktuellen Prozesses.
• Liste der Stakeholder und Nutzer.
• Strukturierte Anforderungen.
• Prioritäten der ersten Phase.
• Annahmen und Einschränkungen.
• Liste der Risiken und Unbekannten.
• Empfohlene Lösungsvariante.
• Vorläufige Architektur oder Mock-up.
• Umsetzungsplan und genauere Kostenschätzung.

Bereite keinen Festpreis vor, wenn der Umfang noch unbekannt ist

Einer der riskantesten Fehler ist es, einen verbindlichen Preis nur deshalb zu nennen, weil der Kunde ihn erwartet. Wenn nicht klar ist, was genau ausgeführt werden soll, beruht jeder konkrete Betrag auf versteckten Annahmen.

Der Auftragnehmer kann eine einfache Version annehmen, der Kunde hingegen eine erweiterte. Der Unterschied kommt erst bei der Umsetzung ans Licht. Es entstehen Nachzahlungen, Konflikte und bei dem Kunden der Eindruck, dass der Freelancer versucht, die früheren Bedingungen zu ändern.

Bei einem unklaren Umfang kann man eine grobe Spanne angeben, die Discovery-Phase kalkulieren oder den ersten Teil nach Stunden abrechnen. Ein Projektpreis ergibt erst dann Sinn, wenn beide Seiten verstehen, welches Ergebnis, welcher Umfang und welches Verantwortungsniveau enthalten sind.

Auf dieser Stufe kann ich lediglich einen Bereich von 15 000–30 000 zł netto angeben, da wir die Anzahl der Integrationen und die Regeln des Datenflusses noch nicht kennen. Ich schlage vor, mit einem kostenpflichtigen Workshop und einer Analyse zu beginnen. Nach dieser Phase erhalten Sie einen empfohlenen Umfang, einen Plan sowie ein genaues Angebot für die Umsetzung.

Beispielantwort

Dokumentiere Annahmen, nicht nur Festlegungen

Bei Projekten mit hoher Unsicherheit ist es wichtig, nicht nur festzuhalten, was die Parteien vereinbart haben, sondern auch, auf welchen Annahmen der Umfang beruht. Wenn der Preis davon ausgeht, dass der Kunde fertige Inhalte liefert, Zugang zu einem bestimmten System gewährt oder eine entscheidungsbefugte Person beteiligt ist, sollte dies ausdrücklich angegeben werden.

Die Annahme kann sich später als falsch erweisen. Das bedeutet nicht automatisch, dass jemand einen Fehler gemacht hat. Wichtig ist, dass die Parteien die Auswirkungen der neuen Information auf Umfang, Preis und Zeitplan bewerten können.

• Was betrachten wir derzeit als Wahrheit?
• Welche Informationen wurden bestätigt?
• Welche Daten fehlen weiterhin?
• Welche Entscheidungen müssen später getroffen werden?
• Was kann den Umfang wesentlich verändern?
• Wer ist für die Überprüfung der einzelnen Annahmen verantwortlich?

Wie kann man die Discovery mit einer konkreten Zusammenfassung abschließen?

Das Gespräch sollte nicht mit dem vagen Gefühl enden, dass beide Seiten das Projekt ungefähr verstehen. Es lohnt sich, eine kurze Zusammenfassung vorzubereiten und den Kunden um eine Bestätigung zu bitten.

1. Beschreibe die aktuelle Situation.
2. Nenne das wichtigste Problem.
3. Nenne die Nutzer und Stakeholder.
4. Bestimme das Hauptziel des Projekts.
5. Definiere das erwartete Ergebnis.
6. Nenne den Umfang der ersten Phase.
7. Halte die Punkte außerhalb des Umfangs fest.
8. Stelle die wichtigsten Annahmen und Risiken dar.
9. Nenne die benötigten Materialien und Entscheidungen des Kunden.
10. Bestimme den nächsten Schritt.

Die Zusammenfassung muss keine lange Spezifikation sein. Sie sollte dem Kunden jedoch ermöglichen zu erkennen, ob der Auftragnehmer seine Situation richtig verstanden hat. Wenn bereits in dieser Phase Unterschiede auftreten, ist es erheblich günstiger, sie vor Beginn der Umsetzung zu klären.

Was sollte man nicht tun, wenn der Kunde seine Bedürfnisse nicht kennt?

Rate nicht für den Kunden

Du kannst Hypothesen und Empfehlungen formulieren, aber sie sollten klar gekennzeichnet sein. Wenn du selbst annimmst, was der Kunde braucht, und dann das gesamte Angebot darauf aufbaust, riskierst du, eine Lösung für ein Problem vorzubereiten, das nicht existiert.

Verwandle das Gespräch nicht in ein Verhör

Eine lange Liste von Fragen, die ohne Kontext gestellt werden, kann den Kunden überfordern. Erkläre, warum eine bestimmte Information benötigt wird, reagiere auf die Antworten und lass Fragen weg, die für das konkrete Projekt keine Relevanz haben.

Schiebe die Antwort nicht zu früh vor

Die Frage „Benötigt ihr eine Anwendung mit einem Administrator-Panel und automatischen Benachrichtigungen?“ lenkt den Kunden in Richtung einer konkreten Lösung. Zuerst fragt man besser, wer die Informationen verwaltet, wie das derzeit gemacht wird und wann die Nutzer kontaktiert werden müssen.

Betrachte Inspiration nicht als Spezifikation

Der Kunde kann die Seite eines Wettbewerbers oder ein Beispielprojekt zeigen und sagen, dass er etwas Ähnliches möchte. Es muss festgestellt werden, welche Elemente für ihn wichtig sind und warum. Die Inspiration kann den Stil, die Struktur, die Funktionen oder den Gesamteindruck betreffen, beschreibt aber selten die vollständigen Anforderungen.

Versprich kein Ergebnis, das noch nicht bewertet werden kann

Wenn du das Problem nicht verstehst, kannst du nicht verantwortungsvoll garantieren, dass die vorgeschlagene Lösung den erwarteten Effekt bringt. Du kannst dich dazu verpflichten, eine Analyse durchzuführen, Empfehlungen vorzubereiten oder einen bestimmten Umfang umzusetzen, aber täusche keine Gewissheit vor, wo es weiterhin wesentliche Unbekannte gibt.

Wann ist es besser, die Zusammenarbeit abzulehnen?

Unklare Bedürfnisse sind an sich noch keine rote Flagge. Das Problem ist die fehlende Bereitschaft, sie gemeinsam zu entdecken. Wenn der Kunde den Umfang nicht kennt, aber auf Fragen antwortet, Materialien bereitstellt und die Analysephase akzeptiert, kann das Projekt eine sehr gute Zusammenarbeit sein.

Das Risiko steigt, wenn der Kunde gleichzeitig nicht in der Lage ist, seine Bedürfnisse zu definieren, die Teilnahme am Discovery verweigert, einen sofortigen Festpreis erwartet und eine vollständige Ergebnisgarantie verlangt. In einer solchen Konstellation übernimmt der Auftragnehmer die Verantwortung für Entscheidungen, für die er keine ausreichenden Informationen erhalten hat.

• Der Kunde möchte grundlegende Fragen nicht beantworten.
• Er stellt die für die Analyse erforderlichen Materialien nicht zur Verfügung.
• Es ist nicht bekannt, wer die Entscheidungen trifft.
• Jeder Stakeholder erwartet etwas anderes, aber niemand möchte Prioritäten festlegen.
• Der Kunde verlangt einen Festpreis, ohne den Umfang festzulegen.
• Er erwartet die kostenlose Ausarbeitung einer vollständigen Strategie oder eines Konzepts.
• Er akzeptiert keinerlei Begrenzungen bei der Anzahl der Änderungen.
• Er möchte, dass der Auftragnehmer ein Ergebnis garantiert, das von vielen externen Faktoren abhängt.

Beispiel: Der Kunde möchte eine „moderne Website“

Der Kunde meldet sich mit der Bitte um die Erstellung einer modernen Unternehmenswebsite. Er weiß nicht, wie viele Unterseiten er benötigt, welche Funktionen darauf enthalten sein sollten oder was Modernität für ihn genau bedeutet.

Anstatt sofort nach dem bevorzugten Stil zu fragen, klärt der Freelancer, warum das Unternehmen eine Änderung in Betracht zieht. Es stellt sich heraus, dass die aktuelle Website vor acht Jahren entstanden ist, auf Mobiltelefonen schlecht funktioniert und ein veraltetes Angebot präsentiert. Die meisten Kunden kommen über Empfehlungen, aber nachdem sie die Website besucht haben, kontaktieren sie das Unternehmen vor allem wegen der günstigsten Dienstleistungen. Das Unternehmen möchte größere B2B-Verträge gewinnen.

Das weitere Gespräch zeigt, dass das Wichtigste nicht allein die Modernisierung des Erscheinungsbilds ist. Die Website soll das Angebot für größere Unternehmen erklären, Referenzen präsentieren, auf typische Bedenken eingehen und potenzielle Kunden zum passenden Formular leiten. Das Unternehmen benötigt hingegen keinen Blog, keinen Shop und kein umfangreiches Kundenportal.

Das unklare Motto wurde in ein konkretes Ziel, eine Zielgruppe, einen Umfang und eine Art der Bewertung des Projekts umgewandelt. Erst in diesem Moment kann man verantwortungsvoll über Struktur, Termin und Preis sprechen.

Beispiel: Der Kunde möchte eine Anwendung zur Verwaltung eines Unternehmens

Die ursprüngliche Anfrage ist sehr breit gefasst: Das Unternehmen möchte eine Anwendung, in der Mitarbeiter Kunden, Aufgaben, Dokumente und Berichte verwalten. Der Versuch, das gesamte System in dieser Phase zu bewerten, wäre reines Rätselraten.

Während des Discoverys stellt sich heraus, dass das größte Problem nicht das Fehlen eines Systems ist, sondern die manuelle Weitergabe von Daten zu neuen Bestellungen zwischen dem Vertrieb und der Auftragsabwicklung. Fehler an dieser Stelle verursachen Verzögerungen und Reklamationen.

Anstatt mit einer umfangreichen Anwendung zu beginnen, kann die erste Phase darin bestehen, das Bestellformular zu strukturieren, eine zentrale Übersicht der Aufträge zu erstellen und die verantwortliche Person automatisch zuzuordnen. Die übrigen Funktionen werden als mögliche Entwicklungsschritte festgehalten, erhöhen aber die Kosten der ersten Version nicht.

Wie kann man das Briefing bei unklaren Bedürfnissen nutzen?

Ein Brief sollte vom Kunden weder Fachwissen noch eine fertige Liste von Lösungen verlangen. Wenn ein Formular mit Fragen zu Technologie, Formaten, Funktionen und einer detaillierten Struktur beginnt, kann eine Person in einer frühen Phase es abbrechen oder zufällige Antworten geben.

Ein besseres Briefing führt den Kunden von den Informationen, die er kennt, zu denen, die gemeinsam präzisiert werden müssen. Zuerst fragt es nach dem Unternehmen, den Zielgruppen, der aktuellen Situation und dem Problem. Anschließend nach dem Ziel, den Prioritäten, Einschränkungen, Materialien, dem Termin sowie dem Budget. Fragen zur Lösung tauchen erst später auf.

Es lohnt sich, dem Kunden die Möglichkeit zu geben, die Antwort „Ich weiß nicht“ oder „Ich brauche eine Empfehlung“ zu wählen. Unsicherheit ist eine wichtige Information. Dank ihr weiß der Freelancer, dass der betreffende Bereich ein Gespräch, eine Analyse oder das Vorstellen von Varianten erfordert.

Beispielhafte Reihenfolge der Fragen im Briefing

1. Womit befasst sich das Unternehmen oder das Projekt?
2. Wer wird das Ergebnis nutzen?
3. Wie löst ihr dieses Problem derzeit?
4. Was funktioniert an der aktuellen Lösung nicht?
5. Warum wollt ihr euch gerade jetzt damit befassen?
6. Welches Ergebnis wird für euch ein Erfolg sein?
7. Welche Elemente sind am wichtigsten?
8. Welche Materialien und Ressourcen sind bereits verfügbar?
9. Wie lautet der erwartete Termin?
10. Welches Budget oder welcher Budgetrahmen ist vorgesehen?
11. Wer wird an der Entscheidungsfindung beteiligt sein?
12. In welchen Bereichen erwartet ihr Empfehlungen des Auftragnehmers?

Wie hilft Briefstreak dabei, unklare Anfragen zu strukturieren?

In Briefstreak kann man ein separates Briefing für eine bestimmte Dienstleistung erstellen und den Kunden durch Fragen in einer logischen Reihenfolge führen. Dank Einzelauswahl- und Mehrfachauswahlantworten, Textfeldern, Anhängen, Fragen zum Termin sowie bedingter Logik kann sich das Formular an die Situation des Kunden anpassen.

Eine Person, die erst noch nach einer Lösung sucht, muss nicht dieselben detaillierten Fragen beantworten wie ein Kunde mit einer fertigen Spezifikation. Sie kann zunächst das Problem und das gewünschte Ergebnis beschreiben. Auf Grundlage dieser Antworten entscheidet der Freelancer, ob er ein Angebot erstellen kann, ein weiteres Gespräch benötigt oder ein bezahltes Discovery vorschlagen sollte.

Ein strukturierter Brief ersetzt weder Denken noch Gespräch. Er begrenzt jedoch den chaotischen Nachrichtenaustausch, macht fehlende Informationen sichtbar und hilft beiden Seiten zu erkennen, welche Entscheidungen bereits getroffen wurden und welche noch ausgearbeitet werden müssen.

Schritt für Schritt Prozess

1. Fordere vom Kunden keine fertige Spezifikation an.
2. Kläre, warum das Projekt gerade jetzt benötigt wird.
3. Bitte um eine Beschreibung der aktuellen Situation und ein konkretes Beispiel des Problems.
4. Trenne den Bedarf von der vom Kunden vorgeschlagenen Lösung.
5. Identifiziere die Nutzer, die entscheidungsbefugte Person und die übrigen Stakeholder.
6. Lege das erwartete Ergebnis sowie die Art seiner Bewertung fest.
7. Analysiere vorhandene Materialien, Daten und Prozesse.
8. Wandle allgemeine Begriffe in konkrete Kriterien um.
9. Lege die Prioritäten sowie den minimal sinnvollen Umfang fest.
10. Notiere Unbekannte, Annahmen und Risiken.
11. Schlage bei Bedarf ein bezahltes Discovery oder einen Prototypen vor.
12. Erst nach der Präzisierung des Umfangs erstelle ein verbindliches Angebot.
13. Sende dem Kunden eine Zusammenfassung und hole seine Bestätigung ein.
14. Behandle spätere neue Informationen als eine Änderung der Annahmen, die bewusst bewertet werden muss.

Zusammenfassung

Ein Kunde, der seine Bedürfnisse nicht genau bestimmen kann, muss weder ein schwieriger noch ein schlecht vorbereiteter Kunde sein. Oft befindet er sich einfach in einer Phase, in der er das Problem besser versteht als die möglichen Lösungen. Gerade dann braucht er am meisten einen Spezialisten, der ihm hilft, die Situation zu ordnen.

Man sollte jedoch nicht alle Lücken mit eigenen Vermutungen füllen. Effektives Discovery ist ein gemeinsamer Prozess: Der Kunde liefert Wissen über sein Unternehmen und seine Nutzer, und der Auftragnehmer hilft dabei, dieses Wissen in Ziele, Prioritäten, Anforderungen und einen realistischen Umfang umzuwandeln.

Am besten beginnt man mit der aktuellen Situation, den konkreten Problemen und der erwarteten Veränderung. Erst danach lohnt es sich, über Funktionen, Erscheinungsbild, Technologie und zu liefernde Materialien zu sprechen. Dadurch ergibt sich die Lösung aus dem Bedarf und nicht aus der ersten Idee, die im Gespräch aufgekommen ist.

Wenn die Ermittlung des Bedarfs ein Audit, Workshops, Datenanalyse oder die Ausarbeitung eines Konzepts erfordert, sollte sie zu einer separaten, kostenpflichtigen Phase werden. Ein Freelancer muss ein komplexes Problem nicht kostenlos lösen, nur um einen Preis nennen zu können.

Das Ziel ist nicht, jede Unbekannte vor dem Start zu beseitigen. In vielen Projekten wird das unmöglich sein. Es geht darum, die wichtigsten Annahmen zu erkennen, das Risiko bewusst zu begrenzen und einen Prozess festzulegen, durch den die nächsten Entscheidungen nicht zufällig getroffen werden.