In Softwareprojekten treffen zwei Welten aufeinander: Auftraggeber, die eine Lösung für ihr Geschäftsproblem suchen, und Entwicklerteams, die diese Lösung technisch umsetzen. Beide Seiten bringen eigene Erfahrungen, Erwartungen und Annahmen mit. Und genau an dieser Schnittstelle entstehen die meisten Reibungsverluste.

Woher die unterschiedlichen Erwartungen kommen

Viele Auftraggeber bringen technisches Vorwissen mit. Sie haben bereits Softwareprojekte begleitet, Artikel über Technologietrends gelesen oder selbst mit Tools gearbeitet. Dieses Wissen ist wertvoll, denn es erleichtert die Kommunikation und hilft, Anforderungen präziser zu formulieren.

Gleichzeitig entsteht daraus eine Herausforderung: Erfahrungen aus einem Kontext lassen sich nicht immer direkt auf einen anderen übertragen. Ein CRM-Projekt mit klar definierten Standardprozessen hat andere Rahmenbedingungen als eine Individualentwicklung mit komplexen Schnittstellenanforderungen. Wer in dem einen Kontext gelernt hat, dass „so etwas in zwei Wochen geht“, hat damit in jenem Kontext recht gehabt. Die Schlussfolgerung, dass es im neuen Kontext genauso schnell gehen muss, führt aber oft zu Diskussionen.

Das ist kein Vorwurf. Es ist ein Strukturproblem. Softwarekomplexität ist von außen schwer einzuschätzen, weil die meisten Aufwandstreiber unsichtbar sind.

Warum Aufwände schwer einzuschätzen sind

Ein Beispiel. „Wir brauchen noch ein Feld im Formular.“ Aus Anwendersicht ist das eine Kleinigkeit. Aus technischer Sicht kann es bedeuten, dass das Datenbank-Schema angepasst, ein Migrationsskript geschrieben, die Validierungslogik ergänzt, der API-Endpunkt erweitert, das Berechtigungskonzept geprüft, die Tests aktualisiert und die Dokumentation nachgezogen werden müssen. Je nach System und Architektur sind das zwei Stunden oder zwei Tage.

Die Diskrepanz zwischen gefühltem und tatsächlichem Aufwand ist einer der häufigsten Konfliktherde in Softwareprojekten. Nicht weil eine Seite die Wahrheit verbiegt, sondern weil beide Seiten von unterschiedlichen mentalen Modellen ausgehen.

Der Auftraggeber denkt in Funktionalität: „Ein Feld mehr, das muss doch schnell gehen.“ Der Entwickler denkt in Systemzusammenhängen: „Ein Feld mehr betrifft sechs Schichten der Anwendung.“ Beide haben aus ihrer Perspektive recht.

Ähnlich verhält es sich mit Technologievorschlägen. „Warum nehmt ihr nicht einfach Tool X?“ ist eine berechtigte Frage. Die Antwort erfordert aber oft eine längere technische Erklärung: Tool X löst ein verwandtes, aber anderes Problem. Es skaliert nicht für den konkreten Anwendungsfall. Es bietet keine Schnittstelle zum vorhandenen ERP-System. Diese Zusammenhänge sind ohne tiefes Wissen über die bestehende Systemlandschaft schwer nachvollziehbar.

Was in der Praxis hilft

Der Schlüssel liegt in transparenter Kommunikation. Nicht als Floskel, sondern als konkretes Vorgehen.

Aufwände aufschlüsseln statt zusammenfassen: Statt „Das dauert 40 Stunden“ besser erklären, woraus sich diese 40 Stunden zusammensetzen. Wenn ein Auftraggeber sieht, dass 8 Stunden auf die Schnittstellenanpassung und 6 Stunden auf die Migrationsskripte entfallen, wird die Zahl nachvollziehbar. Die Gesamtzahl allein wirkt oft willkürlich. Die Aufschlüsselung schafft Vertrauen.

Analogien aus der physischen Welt nutzen: Technische Zusammenhänge werden greifbarer, wenn man sie in bekannte Kontexte übersetzt. „Das ist wie beim Hausbau: Eine zusätzliche Steckdose klingt einfach. Aber wenn die Wand schon verputzt ist, muss aufgestemmt, Kabel gezogen, neu verputzt und gestrichen werden. Die Steckdose selbst ist trivial. Der Kontext macht sie aufwändig.“

Früh und oft abstimmen: Die meisten Erwartungsprobleme entstehen nicht durch bösen Willen, sondern durch zu lange Kommunikationspausen. Wenn der Auftraggeber den Fortschritt regelmäßig sieht, beispielsweise in zweiwöchentlichen Demos, baut sich ein realistisches Gefühl für Komplexität auf. Die Frage „Warum hat das so lange gedauert?“ kommt deutlich seltener, wenn man den Prozess mitverfolgen kann.

Vorwissen als Ressource nutzen statt als Störfaktor behandeln: Auftraggeber, die technische Fragen stellen und Aufwände hinterfragen, sind engagierte Auftraggeber. Sie wollen verstehen, was passiert. Das ist keine Behinderung des Projekts, sondern ein Zeichen dafür, dass ihnen das Ergebnis wichtig ist. Teams, die diese Energie konstruktiv einbinden, statt sie abzuwehren, haben langfristig die besseren Projektbeziehungen.

Die gemeinsame Sprache finden

Die Herausforderung in Softwareprojekten ist selten die Technik. Es ist die Kommunikation zwischen Fachlichkeit und Technik. Beide Seiten müssen investieren: Entwickler müssen lernen, technische Entscheidungen verständlich zu erklären. Auftraggeber müssen bereit sein, der technischen Einschätzung zu vertrauen, auch wenn sie dem eigenen Bauchgefühl widerspricht.

Das funktioniert am besten in einer Projektkultur, in der Fragen willkommen sind. Wo „Warum dauert das so lange?“ nicht als Angriff verstanden wird, sondern als Einladung zur Erklärung. Und wo „Das ist technisch komplexer als erwartet“ nicht als Ausrede abgetan wird, sondern als Information, die beide Seiten für bessere Entscheidungen nutzen.

Fazit

Unterschiedliche Erwartungen in Softwareprojekten sind normal und unvermeidbar. Sie entstehen nicht durch mangelnde Kompetenz auf einer Seite, sondern durch die grundsätzlich verschiedenen Perspektiven, die Auftraggeber und Entwicklungsteams mitbringen. Transparente Aufwandsdarstellung, regelmäßige Abstimmung und der gegenseitige Respekt für die jeweils andere Perspektive sind die Werkzeuge, die aus Reibung produktive Zusammenarbeit machen.