Zu Beginn eines Softwareprojekts ist es besonders hilfreich, das Problem zu beschreiben, bevor die gewünschten Bildschirmseiten aufgelistet werden. Dasselbe Problem kann unterschiedlich gelöst werden: durch bessere Einrichtung eines vorhandenen Werkzeugs, einen veränderten Arbeitsablauf oder eine neue Anwendung.

Welche Aufgabe ist heute schwierig?

Beschreiben Sie statt „Wir brauchen einen Verwaltungsbereich“, bei welcher Arbeit Zeit verloren geht. Ein Team könnte Anfragen in getrennten Dateien verfolgen und dadurch dieselbe Aufgabe doppelt erledigen. Der Bedarf besteht dann nicht nur aus einer Oberfläche, sondern aus gemeinsamen Datensätzen, klaren Verantwortlichkeiten und aktuellen Informationen.

Notieren Sie, wie häufig das Problem auftritt und wen es betrifft. Eine kurze wöchentliche Aufgabe hat möglicherweise eine andere Priorität als ständig wiederholte Arbeit. Listen Sie die bisherigen Schritte möglichst einfach auf.

Wer wird die Lösung nutzen?

Berufsbezeichnungen allein beschreiben die Nutzer nicht ausreichend. Berücksichtigen Sie Arbeitsort, Gerät und benötigte Informationen. Eine Person mit Smartphone im Außendienst hat womöglich andere Erwartungen als jemand vor einem großen Bürobildschirm.

Eine Person erstellt vielleicht eine Anfrage, eine andere genehmigt sie. Dieser Unterschied ist für Berechtigungen und Abläufe wichtig. Besprechen Sie früh, ob jeder Nutzer alle Informationen sehen muss.

Was braucht die erste Version wirklich?

Begrenzen Sie den ersten Umfang auf die Aufgaben, die das Hauptproblem lösen. Trennen Sie notwendige Funktionen, spätere Ergänzungen und Arbeiten außerhalb des Umfangs. Damit wird eine Funktion nicht abgewertet, sondern ihre Reihenfolge festgelegt.

Gemeinsame Anfrageeinträge und Statusverfolgung können zunächst notwendig sein, während detaillierte Berichte später folgen. So lässt sich die tatsächliche Nutzung früher beobachten.

Woran erkennen Sie die Fertigstellung?

„Einfach zu bedienen“ ist verständlich, aber allein nicht messbar. Dass Nutzer eine Anfrage anlegen können, eine berechtigte Person sie sieht und Statusänderungen gespeichert werden, sind konkretere Abnahmekriterien.

Halten Sie zu Beginn einige echte Arbeitsbeispiele fest. Im Projektverlauf helfen sie zu prüfen, ob die Lösung die Erwartungen erfüllt.

Was sollten Sie zum Gespräch mitbringen?

Eine kurze Problembeschreibung, der bisherige Ablauf und die wichtigsten Prioritäten sind ein guter Anfang. Eine fertige technische Spezifikation ist keine Voraussetzung. Machen Sie unbekannte Punkte sichtbar, statt sie zu verstecken.

Mit diesen Informationen steht die Technologieentscheidung auf einer sinnvolleren Grundlage. Zunächst geht es darum, das richtige Problem und seine Grenzen gemeinsam zu verstehen, statt möglichst viele Funktionen zu verlangen.