Hand aufs Herz: Wann ist dein letztes Projekt daran gescheitert, dass PostgreSQL die Daten nicht schnell genug gespeichert hat? Oder daran, dass React einen Button nicht rendern konnte?
Vermutlich nie.
Wir sehen es immer wieder: Technisch läuft alles. Das Team ist motiviert. Aber am Ende steht da eine Software, die niemand so richtig benutzen will. Oder die Prozesse abbildet, die es in der Realität gar nicht gibt.
Das Problem sind selten die Tools. Frameworks funktionieren, Cloud-Plattformen skalieren.
Das Problem ist fast immer: Wir haben nicht verstanden, welches Problem wir eigentlich lösen wollen.
Requirements Engineering klingt oft nach langweiliger Dokumentationsarbeit. Für uns bei vensas ist es etwas anderes: Es ist der Prozess, aus einem schwammigen Problem ein funktionierendes System zu machen.
Weg mit der Feature-Liste
Der Klassiker zum Projektstart: Jemand kommt mit einer Excel-Liste voller Features um die Ecke. "Benutzerverwaltung", "PDF-Export", "Dark Mode".
Das fühlt sich produktiv an, ist aber oft der erste Schritt in die falsche Richtung. Features beschreiben eine Lösung, oft bevor das Problem überhaupt klar ist.
Deshalb fragen wir meistens erst mal anders. Wir suchen den Use Case in der echten Welt.
- Wer sitzt wirklich vor dem Bildschirm?
- Was will diese Person erreichen?
- Wo hakt es heute in ihrem Ablauf?
Wir wollen keine hypothetischen Funktionen bauen ("Wäre cool, wenn man das auch als Excel exportieren könnte"), sondern reale Probleme lösen.
Das Ergebnis ist keine Feature-Liste, sondern ein Kern-Use-Case. Eine Geschichte, die beschreibt, wie die Software das Leben eines Nutzers besser macht.
Der frühe vertikale Durchstich
Statt wochenlang Konzepte zu schreiben und Datenbankdiagramme zu malen, machen wir so früh wie möglich einen vertikalen Durchstich.
Was heißt das konkret?
Wir bauen keinen kompletten Login, keine fertige Datenbank-Architektur und erst recht kein poliertes Design. Wir bauen einen einzigen, schmalen Pfad durch das System, der funktioniert.
Stell dir vor, du baust einen Webshop. Der vertikale Durchstich wäre nicht der Warenkorb oder die Produktsuche. Es wäre vielleicht:
- Eine statische Seite mit einem "Kaufen"-Button.
- Der Nutzer klickt drauf.
- Der Server empfängt den Klick.
- Es wird ein Eintrag in der Datenbank erzeugt ("Bestellung #1").
Klingt banal? Ist es auch. Aber was wir damit beweisen:
- Das Deployment auf die echte Umgebung ("Production") funktioniert.
- Frontend und Backend können miteinander reden.
- Die Datenbank-Verbindung steht.
Sobald dieser Pfad steht, sind die größten technischen Risiken ("Wir kriegen das System nicht live") vom Tisch. Ab jetzt können wir uns voll auf die Fachlichkeit konzentrieren. Ein kleiner funktionierender Ausschnitt schafft mehr Klarheit als 40 Seiten Spezifikation.
80/20: Konzentriere dich auf den Kern
In jedem System gibt es diesen einen Prozess, der 80% des Wertes liefert. Vielleicht ist es der schnelle Checkout im Shop. Oder die Termineingabe im Kalender.
Alles andere – Passwort vergessen, Profilbild ändern, Rechnungsarchiv – ist wichtig, aber nicht entscheidend für den Start.
Wir versuchen, uns radikal auf diesen Kern-Use-Case zu konzentrieren. Wenn der funktioniert und echten Nutzern hilft, haben wir gewonnen. Der Rest ist Fleißarbeit.
Versuchst du, alles gleichzeitig zu lösen, löst du am Ende oft gar nichts richtig.
Klingt logisch? In der Praxis ist es eine der schwierigsten Disziplinen. Auch wir tappen immer wieder in die Falle, uns in Details zu verlieren, bevor der Kern steht.
Unterstützung benötigt?
Du hast das Gefühl, bei euch wird mehr über Features diskutiert als über echte Probleme? Wir helfen dir, den Fokus zurückzugewinnen. Lass uns gemeinsam deinen Kern-Use-Case schärfen und den ersten Durchstich planen. Meld dich einfach.
Im nächsten Teil dieser Serie schauen wir uns an, wie wir diesen Prozess in einem iterativen Zyklus am Laufen halten – ohne im Chaos zu versinken.