Nachdem Sie einmal individuelle Software in Auftrag gegeben haben, wissen Sie Dinge, die Sie vorher nicht wussten. Nicht weil das Projekt gescheitert ist — manchmal war es ein Erfolg — sondern weil die Erfahrung Sie Dinge lehrt, die kein Briefing-Dokument oder Verkaufsgespräch abdeckt.
Wir haben mit vielen Unternehmensinhaber gesprochen, die mindestens ein Softwareprojekt durchlaufen haben. Wenn wir fragen, was sie beim nächsten Mal anders machen würden, tauchen immer wieder dieselben fünf Lektionen auf. Keine davon ist kompliziert. Aber sie sind leicht zu übersehen, wenn man es zum ersten Mal macht.
1. Ihr Brief ist nicht dasselbe wie Ihre Anforderungen
Die meisten Kunden kommen zum ersten Meeting mit einer gut durchdachten Beschreibung dessen, was sie wollen. In der Regel ist es ein Dokument, eine Präsentation oder eine detaillierte E-Mail, die gewünschte Funktionen, erwartete Nutzer und das ungefähre Budget beschreibt.
Das ist ein guter Ausgangspunkt. Aber es ist nicht dasselbe wie ein Anforderungskatalog.
Der Unterschied wird klar, sobald die Entwicklung beginnt. Ein Brief beschreibt eine Idee von außen — was die Software tun soll. Anforderungen beschreiben, wie die Software tatsächlich funktionieren muss, Schritt für Schritt, für jeden Nutzertyp, in jedem Szenario, das auftreten kann.
Die Lücke zwischen diesen beiden Dingen ist der Ort, an dem die meisten Projektprobleme entstehen.
Ein Unternehmensinhaber könnte schreiben: „Nutzer sollen Bestellungen aufgeben können." Ein Entwickler, der auf dieser Grundlage baut, wird fragen: Welcher Nutzertyp? Welche Produkte können bestellt werden und in welchen Kombinationen? Was passiert, wenn ein Artikel nicht vorrätig ist? Welche Bestätigung erhält der Nutzer? Können Bestellungen storniert werden, und wenn ja, von wem und bis wann? Was passiert, wenn die Zahlung fehlschlägt?
Jede dieser Fragen hat eine Antwort, die beeinflusst, wie die Software gebaut wird. Wenn diese Antworten während der Entwicklung — statt vorher — gefunden werden, entstehen Verzögerungen, Nacharbeiten und manchmal grundlegende Neugestaltungen.
Was erfahrene Kunden anders machen: Sie reservieren Zeit für eine strukturierte Anforderungsphase, bevor irgendein Code geschrieben wird. Sie beziehen die Menschen, die das System tatsächlich nutzen werden, frühzeitig in das Gespräch ein. Sie betrachten den Aufwand für die Definition von Anforderungen nicht als Hindernis vor dem Start — sondern als den Beginn des Projekts selbst.
2. Interne Abstimmung ist wichtiger als erwartet
Die Entscheidung, Software in Auftrag zu geben, trifft oft eine Person: der Inhaber, der Geschäftsführer oder der Abteilungsleiter. Aber die Software selbst wird von einer viel breiteren Gruppe von Menschen genutzt — und diese Menschen haben oft sehr unterschiedliche Vorstellungen davon, was sie brauchen.
Diese Lücke zwischen dem Entscheidungsträger und dem Endnutzer ist eine der beständigsten Quellen von Reibung in Projekten. Sie taucht in der Regel etwa auf halbem Weg durch die Entwicklung auf, wenn interne Stakeholder die erste Version sehen und feststellen, dass sie nicht ganz dem entspricht, was sie sich vorgestellt hatten.
Manchmal ist die Diskrepanz klein und leicht zu beheben. Manchmal ist sie groß genug, um erhebliche Nacharbeiten zu erfordern. In jedem Fall kostet es Zeit und Geld, die nicht nötig gewesen wären, wenn die richtigen Personen früher am Tisch gesessen hätten.
Das ist keine Kritik an Kunden. Die meisten Unternehmen sind beschäftigt, interne Prozesse sind komplex, und alle auf einen Nenner zu bringen erfordert Aufwand. Aber die Kosten dieses Aufwands sind fast immer geringer als die Kosten für die Behebung von Fehlausrichtungen während der Entwicklung.
Was erfahrene Kunden anders machen: Sie identifizieren die wichtigsten internen Stakeholder — Abteilungsleiter, Teamleiter, Power-User — bevor das Projekt beginnt, und beziehen sie in den Anforderungsprozess ein. Sie führen interne Workshops durch, sammeln widersprüchliche Meinungen und lösen sie, bevor sie dem Entwicklungsteam ein einheitliches Brief präsentieren. Sie bauen interne Ausrichtung genauso explizit auf, wie sie jeden anderen Teil des Projektplans aufbauen würden.
3. Das erste Angebot entspricht selten dem endgültigen Preis — und das ist kein Zeichen von Unehrlichkeit
Einer der beunruhigendsten Momente in einem Softwareprojekt ist, wenn der Preis beginnt, von dem ursprünglich genannten Betrag abzuweichen. Das kann sich wie ein Lockangebot anfühlen — und in seltenen Fällen von schlechten Akteuren ist es das. Aber viel häufiger spiegelt es etwas Einfacheres wider: Das Projekt war nicht vollständig definiert, als die erste Schätzung gegeben wurde.
Software-Angebote sind Schätzungen, keine Festpreise — es sei denn, der Umfang ist festgelegt, die Anforderungen sind detailliert, und die Unbekannten sind gelöst. Wenn ein Unternehmen Ihnen ein Angebot auf Basis eines Briefs statt einer detaillierten Spezifikation gibt, schätzen sie auf der Grundlage von Annahmen. Wenn diese Annahmen während der Planung und Entwicklung an der Realität getestet werden, passt sich die Zahl an.
Das ist keine Unehrlichkeit. So funktioniert die Schätzung bei komplexen, maßgeschneiderten Arbeiten. Ein Bauunternehmen kann Ihnen keinen Festpreis für ein Gebäude geben, ohne die Bodenuntersuchung, die Architekturzeichnungen und die Materialspezifikation gesehen zu haben. Ein Softwareunternehmen steht vor derselben Herausforderung.
Die Kunden, die sich am meisten durch Budget-Überraschungen betrogen fühlen, sind in der Regel diejenigen, die eine frühe Schätzung als Verpflichtung behandelt haben, bevor die Anforderungen solide waren.
Was erfahrene Kunden anders machen: Sie fragen in verschiedenen Phasen nach Schätzungen — eine grobe Spanne in der Brief-Phase, eine detailliertere Zahl nach der Discovery-Phase und einen Festpreis (wenn das gewünscht ist) erst, nachdem die Anforderungen gründlich definiert sind. Sie bauen eine Pufferreserve in ihr Budget ein — in der Regel 15 bis 20 Prozent — um Änderungen abzudecken, die fast immer entstehen. Sie fragen das Entwicklungsteam konkret, welche Annahmen der Schätzung zugrunde liegen.
4. „Funktioniert" und „bereit zur Nutzung" sind zwei verschiedene Dinge
Es gibt eine Phase in fast jedem Softwareprojekt, in der das Entwicklungsteam bekannt gibt, dass das Feature fertig ist. Und dann kommt der Moment, in dem man es zum ersten Mal benutzt und feststellt, dass — obwohl es technisch funktioniert — etwas daran nicht ganz stimmt.
Die Schaltfläche ist an der falschen Stelle. Der Workflow entspricht nicht der Art, wie das Team tatsächlich arbeitet. Die Beschriftungen verwenden Fachbegriffe, die niemand im Büro versteht. Die wichtigste Funktion erfordert drei zusätzliche Klicks, die alles verlangsamen.
Das bedeutet nicht, dass die Software defekt ist. Es bedeutet, dass Software Testing und Feedback braucht, bevor sie wirklich einsatzbereit ist — und dieses Testing muss von echten Nutzern durchgeführt werden, die echte Aufgaben erledigen, nicht nur von Entwicklern, die überprüfen, ob der Code läuft.
Diese Phase wird Abnahmetest (User Acceptance Testing) genannt, und hier wird ein erheblicher Teil des praktischen Wertes des Projekts geformt. Es ist auch die Phase, in die viele Erstkunden zu wenig investieren. Sie sehen sie als Formalität — ein Häkchen vor dem Launch — statt als wesentlichen Teil des Aufbaus von etwas, das Menschen tatsächlich gut nutzen werden.
Was erfahrene Kunden anders machen: Sie planen Zeit und Kapazität für ordentliches Nutzertesting vor dem Go-live. Sie beziehen echte Nutzer — nicht nur Manager — in die Überprüfung jedes Features ein. Sie behandeln Feedback aus Tests als erwartet und wertvoll, nicht als Beweis dafür, dass etwas schiefgelaufen ist. Sie geben dem Entwicklungsteam strukturiertes, spezifisches Feedback statt allgemeiner Eindrücke.
5. Die Beziehung zum Entwicklungspartner ist wichtiger als der Vertrag
Bevor ein Projekt beginnt, fühlt sich der Vertrag wichtig an. Er definiert, wer für was verantwortlich ist, was passiert, wenn etwas schiefgeht, und wie Streitigkeiten gelöst werden. Diese Dinge sind wichtig, und ein guter Vertrag ist es wert, ihn zu haben.
Aber im Laufe eines echten Projekts kommt der Vertrag selten zur Sprache. Was ständig auftaucht — in jedem Meeting, jeder E-Mail, jeder Entscheidung — ist die Qualität der Beziehung zwischen dem Kunden und dem Entwicklungsteam.
Ein guter Entwicklungspartner wird Ihnen sagen, wenn das, was Sie angefordert haben, nicht der beste Ansatz ist. Er wird darauf hinweisen, wenn der Umfang wächst, bevor es zum Problem wird. Er wird technische Einschränkungen in einfacher Sprache erklären, statt sich hinter Fachjargon zu verstecken. Er wird Ihre Geschäftsziele als Erfolgsmaßstab betrachten, nicht nur die Aufgabenliste.
Eine schwierige Beziehung — selbst mit technisch kompetenten Entwicklern — produziert Projekte, in denen Probleme schwelen, Fragen unbeantwortet bleiben, Feedback nicht gehört wird und beide Seiten am Ende unzufrieden sind, obwohl alle technisch gesehen ihren Job gemacht haben.
Erfahrene Kunden achten genauso auf die Qualität der Kommunikation im Verkaufsprozess wie auf die technischen Qualifikationen und den Preis. Denn die Gespräche während einer Angebotsphase sagen Ihnen viel darüber, wie die Gespräche während der Entwicklung sein werden.
Was erfahrene Kunden anders machen: Sie achten darauf, wie reaktionsschnell, ehrlich und klar das Entwicklungsunternehmen ist, bevor sie irgendetwas unterzeichnen. Sie suchen nach Partnern, die tiefgehende Fragen stellen, Annahmen hinterfragen und ihre Überlegungen erklären — nicht nur nach denen, die allem zustimmen und schnelle Lieferung versprechen. Sie investieren in die Beziehung selbst: regelmäßige Kommunikation, zeitnahes Feedback und die Behandlung des Entwicklungsteams als Mitarbeiter statt als Auftragnehmer.
Keine dieser Lektionen erfordert ungewöhnliche Einsicht, um sie zu verstehen. Sie sind gesunder Menschenverstand, sobald man sie in der Praxis erlebt hat. Die Herausforderung besteht darin, dass sie leicht zu unterschätzen sind, bevor das Projekt beginnt — wenn alles noch voller Möglichkeiten erscheint und es verfrüht scheint, sich Gedanken darüber zu machen, was schiefgehen könnte.
Genau dann kommt es am meisten darauf an, darüber nachzudenken.
Wenn Sie ein Softwareprojekt planen und einige dieser Punkte vor dem Start durchdenken möchten, sprechen Sie mit uns. Diese Gespräche sind immer einfacher, bevor der Vertrag unterzeichnet ist.