Typische Geschichte: Eins bestellt, etwas anderes bekommen, doppelt bezahlt

In meiner unternehmerischen Praxis bin ich oft in die Situation geraten, dass man Softwareentwicklung – sei es ein CRM, ein Buchhaltungssystem oder auch nur ein einfaches Modul – in Auftrag gibt und am Ende nicht ganz das bekommt, was man sich vorgestellt hat. Diese „typische Geschichte“ endet meistens gleich: verschwendete Zeit, Nerven und, was am unangenehmsten ist, doppelte Bezahlung für Überarbeitungen oder den Start eines neuen Projekts von Grund auf. Das ist einer der Hauptgründe, warum ich mit 61 Jahren begonnen habe, formspace.design selbst zu entwickeln, da ich verstanden habe, wie wichtig es ist, das Geplante präzise umzusetzen.

Die Wurzel des Problems: Warum Erwartungen und Realität auseinanderklaffen

Der Hauptgrund für die Diskrepanz zwischen dem, was der Kunde wünscht, und dem, was er erhält, liegt in ineffektiver Kommunikation. Programmierer und Geschäftsanwender sprechen unterschiedliche Sprachen. Ich als Geschäftsmann denke in Kategorien von Aufgaben, Prozessen, Gewinn und Kundennutzen. Der Programmierer hingegen denkt in Kategorien von Code, Architektur, Datenbanken und Algorithmen. Ohne einen zuverlässigen „Übersetzer“ oder ein klares Informationsübertragungssystem können diese beiden Welten oft nicht zusammenfinden. Oft habe ich beobachtet, wie ein Projekt, das 3 Monate dauern sollte, 6-9 Monate in Anspruch nahm und das Budget um 50-100 % explodierte, einfach weil sich die Vision unterwegs änderte oder von Anfang an unklar war.

Meine Erfahrung: Von „Alkar“ bis „Haus und Garten“

Meine Geschichte der Zusammenarbeit mit Programmierern begann bereits in den 90er Jahren bei der Firma „Alkar“. Damals versuchte ich, die Managementbuchhaltung zu automatisieren, indem ich den Entwicklern Aufgaben stellte. Das war eine Zeit, in der fast alles manuell erledigt wurde, und ich selbst führte die Buchhaltung mit Notizbüchern und einem Taschenrechner, wovon ich bereits im Artikel 90er Jahre: Wie ich bei "Alkar-Invest" die Buchhaltung manuell ohne ein einziges Programm führte erzählt habe. Schon damals, mit begrenzten Möglichkeiten, verstand ich den Bedarf an Automatisierung, aber eine präzise Lösung zu erhalten, war nicht einfach.

Später, als ich über 20 Jahre lang das Landschaftsbauunternehmen „Haus und Garten“ leitete, stieß ich erneut auf dieses Problem, diesmal jedoch in einer akutereren Form. Wir wuchsen, die Anzahl der Projekte nahm zu, und das Fehlen eines adäquaten CRM-Systems wurde zu einem echten Kopfzerbrechen. Ich versuchte, individuelle Lösungen in Auftrag zu geben, stieß aber immer wieder darauf, dass die Funktionalität entweder nicht unseren tatsächlichen Bedürfnissen entsprach, zu komplex war oder ständige Anpassungen erforderte, die ein Vermögen kosteten. Genau da verstand ich, warum die meisten Landschaftsbauunternehmen kein normales CRM haben, worüber ich in diesem Artikel geschrieben habe. Es war ein Teufelskreis: Man gibt Geld aus, bekommt nicht das Richtige, überarbeitet oder fängt von vorne an. Das war eine harte, aber wertvolle Erfahrung, die meine Vision eines idealen Produkts prägte.

Wie man eine technische Spezifikation richtig formuliert, um nicht doppelt zu zahlen

Der Schlüssel zum Erfolg ist eine möglichst klare technische Spezifikation (TS) und ein transparenter Prozess. Das habe ich aus meiner Erfahrung gelernt:

1. Beginnen Sie mit Zielen und Problemen: Nicht einfach „ein CRM erstellen“, sondern „die Bearbeitungszeit von Anfragen um 30 % reduzieren“ oder „die Kalkulation automatisieren, um Fehler zu vermeiden“.
2. Detaillieren Sie die Funktionalität: Beschreiben Sie jeden Bildschirm, jede Schaltfläche, jeden Benutzerschritt. Versetzen Sie sich in die Lage des zukünftigen Benutzers der Software. Es ist besser, Mockups (sogar handgezeichnet) zu erstellen, als nur Text zu beschreiben.
3. Verwenden Sie „User Stories“: Anstatt einer trockenen Funktionsbeschreibung erzählen Sie eine Geschichte: „Als Kunde möchte ich eine Anfrage auf der Website hinterlassen, um innerhalb einer Stunde einen Kostenvoranschlag zu erhalten.“ Dies hilft dem Programmierer, den Kontext zu verstehen.
4. Teilen Sie das Projekt in Phasen auf: Versuchen Sie nicht, alles auf einmal zu erledigen. Teilen Sie ein großes Projekt in kleine, überschaubare Phasen. Dies ermöglicht es, die Funktionalität nach jeder Phase zu testen und Anpassungen vorzunehmen, bevor es zu spät ist.
5. Benennen Sie einen Verantwortlichen: Seitens des Auftraggebers sollte eine Person für die Kommunikation mit den Entwicklern, die Entscheidungsfindung und das Testen zuständig sein. Dies verhindert Chaos und widersprüchliche Anweisungen.

Fallstricke und häufige Fehler des Auftraggebers

Selbst bei einer vorhandenen TS habe ich oft gesehen, wie Projekte aufgrund typischer Fehler seitens des Auftraggebers aus dem Ruder liefen:

• Unzureichende Beteiligung: Die Delegation des gesamten Prozesses und das Fehlen regelmäßiger Kontrolle. Der Auftraggeber muss ein aktiver Teilnehmer sein.
• Änderung der Anforderungen während des Prozesses: „Und lassen Sie uns das noch hinzufügen…“ – jede solche Änderung in späteren Entwicklungsphasen erhöht die Kosten und den Zeitrahmen um ein Vielfaches.
• Ignorieren von Tests: Das Fehlen gründlicher Tests der Funktionalität in jeder Phase führt dazu, dass Fehler erst in der Implementierungsphase entdeckt werden, wenn deren Behebung am teuersten ist. Ich erinnere mich an ein CRM-Projekt für 15 Mitarbeiter, bei dem eine nachlässige Einstellung zum Testen dazu führte, dass das System nach 8 Monaten Arbeit nur zu 70 % der erwarteten Funktionalität bereit war.
• Wahl des günstigsten Angebots: Ein niedriger Preis bedeutet oft geringe Qualität, mangelnden Support oder ein Missverständnis der Geschäftsspezifika.
• Fehlendes Budget für Support und Entwicklung: Software ist ein lebendiger Organismus, der Updates, Fehlerbehebungen und Weiterentwicklungen erfordert. Ohne diese veraltet sie schnell.

Die Rolle von Tests und Feedback

Testen ist nicht nur die Fehlersuche, es ist die Überprüfung der Produktkonformität mit Ihren Erwartungen. Merken Sie sich:

• Regelmäßiges Testen: Nach jedem abgeschlossenen Modul oder jeder Phase.
• Tests mit echten Benutzern (UAT): Lassen Sie diejenigen, die täglich mit dem Programm arbeiten werden, es in frühen Phasen ausprobieren. Ihr Feedback ist von unschätzbarem Wert.
• Konstruktives Feedback: Beschreiben Sie klar, was nicht funktioniert, warum es ein Problem ist und welches Ergebnis Sie erwarten. „Gefällt mir nicht“ ist kein Feedback. „Beim Klicken auf Schaltfläche X passiert nichts, aber ich erwarte, dass Fenster Y erscheint“ – das ist konstruktiv.

Wann man über fertige Lösungen nachdenken sollte

Meine Erfahrung hat mich zu der Erkenntnis gebracht, dass man nicht immer das Rad neu erfinden muss. Für viele typische Aufgaben gibt es fertige Lösungen, die angepasst werden können. Das kann schneller, günstiger und zuverlässiger sein als eine individuelle Entwicklung. Bevor Sie etwas von Grund auf neu in Auftrag geben, führen Sie eine gründliche Marktanalyse durch. Möglicherweise löst ein fertiges CRM, ERP oder ein Planungstool, wie zum Beispiel formspace.design, bereits 80 % Ihrer Aufgaben für deutlich weniger Geld und mit einem vorhersehbaren Ergebnis.

Wie man Fehler bei der Automatisierungsplanung mit formspace.design vermeidet

Bei der Entwicklung von formspace.design habe ich Prinzipien zugrunde gelegt, die es ermöglichen, typische Probleme im Zusammenhang mit Missverständnissen und doppelter Bezahlung zu vermeiden. Ich wollte, dass jeder Grundstückseigentümer selbst der „Architekt“ seiner Landschaft sein kann, ohne seine Ideen Designern oder Programmierern erklären und das Projekt anschließend überarbeiten zu müssen. formspace.design ist ein Tool, das den Planungsprozess maximal transparent und anschaulich macht.

Stellen Sie sich vor, Sie möchten eine Nadelbaum-Ecke im Garten planen. Anstatt dies einem Designer zu erklären oder zu versuchen, es auf Papier zu zeichnen, können Sie formspace.design verwenden. Im Modul 1.x „Grundstücksplan, Zonen und Objekte“ zeichnen Sie mühelos die Umrisse des Grundstücks, platzieren Zonen (z. B. „Ruhezone“, „Nadelbaum-Ecke“) und fügen dann konkrete Objekte hinzu – Nadelbäume und Sträucher. Wenn Sie Fotos haben, können Sie mit Modul 3.1 „Design nach Foto“ sofort sehen, wie diese Pflanzen auf Ihrem Grundstück aussehen würden. Für Inspiration und schnelle Konzepte können Sie Modul 2.1 „KI-Konzept“ nutzen, das Designvarianten basierend auf Ihren Eingaben vorschlägt. So erhalten Sie ein konkretes, visualisiertes Ergebnis, das genau Ihrer Vision entspricht, ohne mehrfache Erklärungen und Überarbeitungen.

Häufig gestellte Fragen

Muss man immer einen Programmierer für die Automatisierung einstellen?

Nein, nicht immer. Für viele typische Aufgaben gibt es fertige SaaS-Lösungen oder Baukästen, die an die eigenen Bedürfnisse angepasst werden können. Die Einstellung eines Programmierers ist gerechtfertigt, wenn Sie eine einzigartige Geschäftslogik oder sehr spezifische Anforderungen haben, die von Standardprodukten nicht abgedeckt werden.

Was ist eine „technische Spezifikation“ einfach erklärt?

Eine technische Spezifikation ist eine detaillierte Beschreibung dessen, was Sie als Ergebnis der Entwicklung erhalten möchten. Es ist eine Art „Blaupause“ Ihres zukünftigen Softwareprodukts, in der alle Funktionen, das Erscheinungsbild, die Arbeitslogik und die Leistungsanforderungen festgelegt sind. Je detaillierter die TS, desto geringer ist die Wahrscheinlichkeit von Missverständnissen.

Wie lange dauert die Entwicklung individueller Software?

Die Dauer hängt stark von der Komplexität des Projekts ab. Eine einfache Unternehmenswebsite kann 1-2 Monate dauern, während ein komplexes CRM-System mit Integrationen 6 Monate bis mehrere Jahre in Anspruch nehmen kann. Es ist wichtig zu bedenken, dass Schätzungen nur Schätzungen sind und die tatsächlichen Fristen aufgrund unvorhergesehener Schwierigkeiten oft länger sein können.

Wie merkt man, dass der Programmierer einen nicht verstanden hat?

Das erste Anzeichen ist, wenn Sie einen Prototyp oder einen Teil der Funktionalität erhalten, der ganz anders aussieht, als Sie es sich vorgestellt haben, oder nach einer anderen Logik funktioniert. Ein weiteres alarmierendes Signal ist das Fehlen von Fragen des Programmierers zu den Details Ihres Geschäfts oder die vollständige Zustimmung zu jedem Ihrer Worte ohne Klärungen.

Sollte man mit einem kleinen Funktionsumfang beginnen?

Ja, das ist ein sehr vernünftiger Ansatz. Beginnen Sie mit einem Minimum Viable Product (MVP), das das Hauptproblem löst. Dies ermöglicht einen schnelleren Markteintritt, das Einholen von Benutzerfeedback und die iterative Weiterentwicklung des Produkts basierend auf realen Bedürfnissen und nicht auf Annahmen.

Kann man „doppelte Bezahlung“ vermeiden?

Risiken vollständig zu vermeiden ist schwierig, aber man kann sie minimieren. Eine klare TS, gestaffelte Zahlungen nach erbrachten Leistungen, regelmäßige Tests und offene Kommunikation mit dem Entwickler reduzieren die Wahrscheinlichkeit von Überzahlungen für Überarbeitungen erheblich.

Welche Rolle spielt meine Erfahrung bei formspace.design?

Meine langjährige Erfahrung im Geschäfts- und Landschaftsdesign, einschließlich aller Fehler und Schwierigkeiten bei der Automatisierung, bildete die Grundlage für die Entwicklung von formspace.design. Ich baue dieses Tool, damit andere Grundstückseigentümer nicht mit dem Problem „eins bestellt, etwas anderes bekommen“ konfrontiert werden, sondern ihre Ideen selbst präzise und anschaulich umsetzen können.

Mein Weg zur Entwicklung von formspace.design ist ein direktes Ergebnis all dieser Geschichten. Ich habe verstanden, dass ein ideales Tool intuitiv, visuell und dem Benutzer die volle Kontrolle über das Ergebnis geben muss, indem es Kommunikationsbarrieren überwindet. Wenn Sie in Ihrem Unternehmen oder bei der Planung Ihres Grundstücks auf ähnliche Probleme gestoßen sind, denken Sie daran: Klarheit, Detaillierung und ständiges Feedback sind Ihre besten Verbündeten. Und für die Landschaftsplanung baue ich ein Tool, das diese Klarheit ohne Zwischenhändler ermöglicht.