Was ich über Softwareentwicklung gelernt habe, indem ich Programmierer jahrelang von außen beobachtet habe

Jahre im Geschäftsleben, insbesondere in einem Bereich fernab der IT, haben mich eines Wichtigen gelehrt: Zwischen „Ich will“ und „Wie man es macht“ klafft in der Welt der Programmierung ein wahrer Abgrund. Ich bin kein ausgebildeter Programmierer – mein Weg begann mit Sport, Malerei und führte dann zu Wirtschaft und Landschaftsgestaltung. Dennoch bin ich seit Anfang der 90er Jahre, als ich NPO „Alkar“ leitete und Programmierern Aufgaben für die Betriebsabrechnung stellte, bis zur Gründung von formspace.design mit 61 Jahren ständig mit der Entwicklung konfrontiert gewesen. Und das habe ich dabei von außen über sie gelernt.

Die Kluft zwischen „Ich will“ und „Wie man es macht“

Das Erste und wohl Wichtigste, was ich erkannt habe, ist der grundlegende Unterschied im Denken. Ein Unternehmer, ein Praktiker, denkt in Kategorien von Aufgaben und Lösungen für den Kunden: „Wir brauchen, dass der Kunde Pflanzen nach bestimmten Kriterien auswählen kann“, „Ich brauche einen Bericht über die Margen der Projekte“. Ein Programmierer hingegen denkt in Kategorien von Code, Algorithmen, Datenstrukturen, Effizienz und Skalierbarkeit. Er sieht den Endbenutzer nicht so, wie ich ihn sehe. Für ihn zerlegt sich die Aufgabe „Pflanzen nach Kriterien auswählen“ in eine Datenbank, Filter, Abfragen, Oberflächenelemente und so weiter. Und oft geht bei dieser Übersetzung die Essenz verloren. Zum Beispiel kann ich sagen: „Ich brauche ein CRM für das Landschaftsbaugeschäft“, was die Verwaltung von bis zu 20 gleichzeitigen Projekten mit 20–30 Parametern für jede Pflanze und einem komplexen Arbeitszyklus impliziert. Der Programmierer kann jedoch mit einem Basis-CRM beginnen, das für jedes Geschäft geeignet ist, ohne sich in die Besonderheiten zu vertiefen.

Die Bedeutung eines klaren Pflichtenhefts und warum es immer „unzureichend“ ist

Ich habe viele technische Spezifikationen erstellt – zuerst für Betriebsabrechnungssysteme bei „Alkar“, dann für die Prozessautomatisierung bei „Haus und Garten“. Und jedes Mal schien es, als hätte ich alles bis ins kleinste Detail beschrieben. Aber nach der ersten Iteration merkte ich, dass etwas fehlte. Programmierer lesen nicht zwischen den Zeilen, sie erraten den Kontext nicht. Wenn ich nicht angegeben habe, dass bei der Berechnung der Kosten für die Pflasterung einer Fläche von 50 m² mit drei Fliesentypen 5 % für Verschnitt und unterschiedliche Verlegepreise für jeden Typ berücksichtigt werden müssen, dann ist die Berechnung eine einfache Multiplikation der Fläche mit dem Preis. Das ist nicht ihre Schuld, das ist meine Verantwortung als Auftraggeber. Ich habe verstanden, dass warum technische Schulden im Geschäft mit einem schlechten Briefing beginnen – eine direkte Folge eines unvollständigen, wenn auch umfangreichen, Pflichtenhefts ist. Jede Unklarheit ist ein potenzieller Fehler oder eine Verzögerung.

Die Denkweise des Programmierers: nicht „was“, sondern „wie“

Programmierer sind Ingenieure, die Brücken aus Code bauen. Ihnen ist die Festigkeit der Konstruktion, ihre Effizienz und Geschwindigkeit wichtig. Mir als Geschäftsinhaber ist es wichtiger, dass die Brücke dorthin führt, wo sie hin soll, und dass Menschen sie passieren können. Das bedeutet nicht, dass die Codequalität unwichtig ist, aber die Prioritäten gehen oft auseinander. Ein Programmierer kann stundenlang eine Abfrage optimieren, die 0,01 Sekunden dauert, damit sie 0,005 Sekunden dauert, während es für das Geschäft wichtiger ist, dass eine neue Funktion erscheint, die Umsatz generiert. Dieser Unterschied im Fokus ist einer der Hauptgründe, warum der Unterschied zwischen einem Produkt von Programmierern und einem Produkt von Praktikern so groß ist. Sie sehen Code, ich sehe eine Lösung für das Problem des Kunden.

Technische Schulden und ihre Wurzeln in der Kommunikation

Technische Schulden sind nicht nur „schlechter Code“. Sie sind in erster Linie das Ergebnis von Kompromissen, die während der Entwicklung aufgrund unklarer Anforderungen oder des Strebens nach schnellen Ergebnissen ohne angemessene Planung eingegangen wurden. Ich erinnere mich an einen Fall, als ich dringend eine neue Berechnungsart zur Bestimmung der Margen von Dienstleistungen einführen musste. Der Programmierer baute eine „schnelle Notlösung“, die funktionierte, aber stark an eine bestimmte Dienstleistung gebunden war. Ein halbes Jahr später, als neue Dienstleistungen hinzukamen und die Berechnung skaliert werden musste, wurde diese „Notlösung“ zu einem riesigen Problem, das eine komplette Überarbeitung erforderte. Was am Anfang mit der richtigen Planung ein paar Tage gedauert hätte, wurde zu wochenlanger Arbeit und Tausenden von Dollar Kosten. Dies ist ein typisches Beispiel dafür, wie die mangelnde Bereitschaft oder Unfähigkeit, sich zu Beginn tief in die Geschäftslogik einzutauchen, zu langfristigen Problemen führt.

Wie ich gelernt habe, ihre Sprache zu sprechen (oder sie zumindest zu verstehen)

Im Laufe der Jahre habe ich verstanden, dass der einzige Weg, diese Kluft zu überwinden, darin besteht, selbst ein besseres Verständnis der Entwicklungslogik zu erlangen. Das bedeutet nicht, dass ich ein professioneller Programmierer geworden bin, aber ich begann, die Grundlagen zu studieren, die Systemarchitektur zu verstehen und die Funktionsweise von Datenbanken zu begreifen. Und mit dem Aufkommen der KI, mit 61 Jahren, erhielt ich ein Werkzeug, das es mir ermöglichte, nicht nur Aufgaben zu stellen, sondern sie zu formulieren, direkt mit dem „Code“ zu kommunizieren, meine Hypothesen zu überprüfen und sogar Prototypen zu erstellen. Das gab mir unglaubliche Freiheit und die Möglichkeit, formspace.design ohne ein Team von Programmierern aufzubauen. Dies ist ein Weg, der jedem offensteht, der bereit ist, sich in das Thema zu vertiefen und Disziplin zu zeigen.

Wenn das Produkt „hier und jetzt“ benötigt wird und nicht „wenn es fertig ist“

Ein Unternehmen kann nicht jahrelang auf das perfekte Produkt warten. Es braucht ein MVP (Minimum Viable Product) – ein minimal überlebensfähiges Produkt, das das Hauptproblem des Kunden löst, auch wenn es nicht perfekt ist. Programmierer streben oft nach Perfektion, nach einer makellosen Architektur, nach Fehlerfreiheit. Das ist lobenswert, aber in der realen Welt bedeutet es verpasste Gelegenheiten und verlorene Kunden. Meine Erfahrung hat mich gelehrt, Geschwindigkeit und Iteration zu schätzen. Es ist besser, ein Produkt mit 80 % der wirklich benötigten Funktionen zu veröffentlichen und es schnell auf der Grundlage von Feedback zu überarbeiten, als 100 % der Funktionen zu perfektionieren, die sich möglicherweise als unnötig erweisen.

Wie sich meine Erfahrung in formspace.design widerspiegelt

All diese Jahre der Beobachtung und Zusammenarbeit mit Programmierern, all meine „Schmerzen“ und „Erkenntnisse“ bildeten die Grundlage von formspace.design. Ich habe es als Werkzeug geschaffen, das diese scharfen Kanten maximal glättet. Ich wollte es für Landschaftsarchitekten und Grundstücksbesitzer intuitiv verständlich machen, damit sie ihre Ideen umsetzen können, ohne sich in technische Details zu vertiefen. Das Fehlen eines Programmiererteams und der Einsatz von KI in der Entwicklung ermöglichten es mir, ein Produkt zu schaffen, das die realen Bedürfnisse des Marktes widerspiegelt und nicht nur technische Möglichkeiten. Es ist ein Produkt, das ich selbst in meiner Praxis haben wollte.

Wie man eine Landschaft in formspace.design plant

Stellen Sie sich vor, Sie möchten auf einem 15 Ar großen Grundstück einen Ruhebereich mit einer Pergola und einem kleinen Teich anlegen. formspace.design wurde als Brücke zwischen Ihrer Idee und ihrer Umsetzung entwickelt, ohne komplizierte Erklärungen mit technischen Spezialisten. Zuerst würde ich ein Luftbild hochladen oder den Umriss des Grundstücks in Modul 1.0 „Grundstücksplan“ zeichnen. Dies ermöglicht eine schnelle Grundlage für die Arbeit.

Anschließend würde ich mithilfe der Zonierungsmodule (1.1 „Zonen“) den Platz für den Ruhebereich, den Spielplatz und den Gemüsegarten festlegen, unter Berücksichtigung der Himmelsrichtungen und des Gefälles. In Modul 2.1 „KI-Konzept“ können Sie mehrere Designvarianten erhalten, indem Sie einfach Ihre Wünsche beschreiben. Zum Beispiel: „moderner Stil, Minimalismus, überwiegend Nadelgehölze“. Die KI schlägt Ideen vor, die dann durch Hinzufügen von Objekten (1.2 „Objekte“) – dieselbe Pergola, Bänke, Leuchten – detailliert werden können. Und Modul 3.1 „Design nach Foto“ ermöglicht es Ihnen, zu sehen, wie die ausgewählten Elemente auf einem realen Bild Ihres Grundstücks aussehen würden. Dies ermöglicht es, das Gesamtbild zu sehen und viele Fehler bereits vor Beginn der Arbeiten zu vermeiden, ohne auf teure Dienstleistungen von Planern oder lange Erklärungen mit den Ausführenden zurückgreifen zu müssen.

Häufig gestellte Fragen (FAQ)

Kann ich ohne Programmierer auskommen, wenn ich KI habe?

KI vereinfacht den Entwicklungsprozess erheblich und ermöglicht es Nicht-Programmierern, komplexe Produkte zu erstellen, wie ich es mit formspace.design getan habe. Es ist jedoch noch schwierig, vollständig ohne ein Verständnis der grundlegenden Programmierprinzipien oder ohne externe Hilfe in komplexen Phasen auszukommen. KI ist ein mächtiger Helfer, aber kein Ersatz für tiefgreifendes Wissen.

Was ist der Hauptunterschied im Ansatz zwischen Business und IT?

Das Business ist auf das Endergebnis, die Lösung von Kundenproblemen und die Gewinnerzielung ausgerichtet. IT-Spezialisten konzentrieren sich auf den Erstellungsprozess, die Codequalität, deren Effizienz und Skalierbarkeit. Der Hauptunterschied liegt in den Prioritäten: Das Business schätzt Geschwindigkeit und Funktionalität, die IT – Zuverlässigkeit und architektonische Sauberkeit.

Wie vermeidet man endlose Überarbeitungen und Neuentwicklungen?

Der Schlüssel zum Erfolg ist ein möglichst detailliertes und eindeutiges Pflichtenheft sowie ein iterativer Ansatz mit häufigem Feedback. Teilen Sie das Projekt in kleine, überprüfbare Phasen (MVP) auf und testen Sie jede Funktion sofort nach ihrer Implementierung. Dies ermöglicht es, den Kurs zu korrigieren, bevor Fehler kritisch werden.

Lohnt es sich, die Grundlagen des Codierens zu lernen, um die Kommunikation zu verbessern?

Ich glaube ja. Es ist nicht notwendig, ein professioneller Programmierer zu werden, aber das Verständnis grundlegender Konzepte (Logik, Datenstrukturen, Funktionsweise von APIs) verbessert Ihre Fähigkeit, Aufgaben zu stellen und die Antworten der Entwickler zu verstehen, erheblich. Es ist wie das Erlernen einiger Sätze in einer Fremdsprache, um sich in einem neuen Land besser zurechtzufinden.

Warum verstehen Programmierer oft „offensichtliche“ Dinge für das Business nicht?

Was für das Business „offensichtlich“ erscheint, basiert oft auf jahrelanger Erfahrung in einer bestimmten Nische und impliziten Annahmen. Ein Programmierer, der diese Erfahrung nicht hat, kann diese Annahmen nicht als „offensichtlich“ betrachten. Er arbeitet mit dem, was explizit beschrieben ist. Ihre Aufgabe ist es, das Implizite explizit zu machen, indem Sie den Kontext und die Geschäftslogik so detailliert wie möglich beschreiben.

Wie wählt man den richtigen Entwickler für sein Projekt aus?

Suchen Sie nach Entwicklern, die Interesse an Ihrem Fachgebiet zeigen und viele Fragen zu den Geschäftsprozessen stellen. Wichtig ist nicht nur ihr technischer Stack, sondern auch ihre Empathiefähigkeit, der Wunsch zu verstehen, wofür sie das Produkt entwickeln. Überprüfen Sie unbedingt ihr Portfolio und ihre Referenzen, vorzugsweise mit Projekten, die Ihrem ähneln.

Ist mein Produkt zu nischig, um es zu automatisieren?

Ja, Nischenprodukte profitieren oft am meisten von der Automatisierung, da Standardlösungen selten perfekt passen. Die Entwicklung eines spezialisierten Tools, auch wenn es klein ist, kann einen enormen Wettbewerbsvorteil verschaffen und die Effizienz erheblich steigern. Genau auf dieser Nischenerfahrung wurde formspace.design aufgebaut.

Was sind „technische Schulden“ aus geschäftlicher Sicht?

Aus geschäftlicher Sicht sind technische Schulden versteckte Kosten, die in Zukunft aufgrund von Entscheidungen entstehen, die jetzt getroffen wurden, um Zeit oder Ressourcen zu sparen. Es ist wie ein Kredit aufzunehmen: Man bekommt jetzt etwas, zahlt aber später Zinsen. Diese „Zinsen“ äußern sich in Form einer Verlangsamung der Entwicklung neuer Funktionen, häufiger Fehler, Schwierigkeiten bei der Skalierung und hohen Kosten für die Produktwartung.

Mein Weg zu formspace.design war lang, voller Fehler und Entdeckungen im Umgang mit der Welt der Entwicklung. Aber jede dieser Erkenntnisse hat mich stärker gemacht und geholfen, ein Produkt zu schaffen, das hoffentlich Tausenden von Menschen nützlich sein wird. Das Wichtigste ist, sich nicht zu scheuen, sich in das, was komplex erscheint, zu vertiefen, und immer daran zu denken, für wen und warum man sein Produkt schafft. Das ist die wahre Erfahrung.

Verwandte Artikel

• Weiterlesen