Von der Idee zum Prototyp in Tagen: Voraussetzungen und praktischer Fahrplan

Ein Software-Prototyp kann innerhalb weniger Tage zeigen, ob eine Idee technisch und im Arbeitsalltag trägt. Voraussetzung ist eine klar begrenzte Fragestellung statt des Versuchs, sofort die gesamte Unternehmenssoftware zu ersetzen. Wenn vorhandene Werkzeuge Ihren Prozess nicht passend unterstützen, liefert ein gezielter Prototyp eine bessere Entscheidungsgrundlage als die Auswahl eines weiteren Werkzeugs auf Verdacht.

Was ein Prototyp leisten soll

Ein Prototyp macht eine wichtige Annahme überprüfbar. Das kann die Bedienbarkeit einer Erfassungsmaske sein, die Verfügbarkeit von Daten über eine Schnittstelle oder die Eignung einer KI-Auswertung. Er muss dafür ausreichend realistisch sein, aber noch nicht sämtliche Anforderungen des späteren Betriebs erfüllen.

Unterscheiden Sie drei Ergebnisse: Ein klickbarer Entwurf prüft Bedienung und Verständnis. Ein technischer Machbarkeitstest prüft eine Verbindung oder Berechnung. Ein durchgängiger Prozessprototyp verbindet einen begrenzten Eingang mit einem sichtbaren Ergebnis. Welche Form sinnvoll ist, hängt davon ab, welche Unsicherheit Ihre nächste Entscheidung blockiert.

Die GOV.UK-Anleitung zum Prototyping betont entsprechend das schnelle Erkunden und Testen von Ideen. Sie unterscheidet ausdrücklich zwischen Prototypcode und produktionsreifem Code. Eine überzeugende Vorführung ist deshalb noch kein Beleg dafür, dass eine Lösung zuverlässig mit echten Daten, mehreren Nutzern und laufenden Änderungen betrieben werden kann.

Diese Voraussetzungen verkürzen den Weg

Ein Verantwortlicher mit fachlicher Entscheidungskompetenz

Benennen Sie eine Person, die offene Fragen zeitnah beantworten und den Umfang begrenzen kann. Wenn jede Feldbezeichnung erst durch mehrere Abstimmungsrunden muss, wird aus einem kurzen Entwicklungsabschnitt schnell eine lange Wartephase. Vereinbaren Sie außerdem früh einen Termin mit späteren Anwendern, damit der Prototyp nicht ausschließlich aus Entwicklersicht bewertet wird.

Beispiele und Zugänge vor dem Start

Stellen Sie typische Eingaben, gewünschte Ergebnisse und einige schwierige Fälle bereit. Bei einer Integration gehören Schnittstellendokumentation, Testzugang und benötigte Berechtigungen dazu. Sind diese Voraussetzungen offen, kann zunächst ein simulierter Ablauf entstehen. Dokumentieren Sie dann klar, welche Verbindung noch nicht technisch nachgewiesen ist.

Eine Frage, die sich wirklich beantworten lässt

„Wir möchten effizienter arbeiten“ ist ein Ziel, aber keine prüfbare Prototypfrage. Konkreter wäre: „Kann das Büro eine eingehende Anfrage mit den vorhandenen Daten eindeutig einem Kunden zuordnen und eine vollständige Aufgabe erzeugen?“ Daraus lassen sich Testfälle, eine kleine Oberfläche und nachvollziehbare Abnahmekriterien ableiten.

Ein kompaktes Anforderungsblatt statt eines großen Wunschkatalogs

Halten Sie den ersten Umfang auf einer Seite fest. Beschreiben Sie den Ausgangspunkt, die gewünschte Handlung und das erwartete Ergebnis. Ergänzen Sie bewusste Grenzen: Welche Rollen, Datenquellen und Sonderfälle werden in diesem Durchlauf betrachtet? Eine solche Eingrenzung ist eine Arbeitsvereinbarung und keine Aussage darüber, was die spätere Lösung insgesamt können darf.

• Nutzer: Wer erledigt die Aufgabe, und mit welchem Vorwissen?
• Eingang: Welche Daten stehen in welcher Qualität zur Verfügung?
• Ergebnis: Was muss nach dem Test sichtbar oder gespeichert sein?
• Kritische Annahme: Welche offene Frage gefährdet den Nutzen am stärksten?
• Abnahme: An welchen konkreten Fällen wird das Ergebnis beurteilt?
• Grenzen: Welche Funktionen sind erst für einen späteren Schritt vorgesehen?

Praktischer Fahrplan für einen kurzen Entwicklungsabschnitt

Die folgende Reihenfolge ist ein beispielhafter Plan für einen eng begrenzten Prototyp bei bereitstehenden Zugängen und zeitnahem Feedback. Die Tagesangaben sind Orientierung, keine zugesagte Lieferzeit. Je nach technischer Unsicherheit kann ein einzelner Abschnitt mehrere Tage oder länger benötigen.

Testen Sie die riskanteste Annahme früh. Wenn eine benötigte Schnittstelle das entscheidende Datenfeld nicht liefert, sollten Sie das vor der Gestaltung einer aufwendigen Oberfläche erfahren. Auch der GOV.UK-Leitfaden zur Alpha-Phase empfiehlt, Prototypen auf besonders unsichere Annahmen zu konzentrieren. Dessen umfassendere Projektphasen sind allerdings kein Beleg für einen pauschalen Fünf-Tage-Zeitrahmen.

Hypothetisches Beispiel: Eine interne Anfrageübersicht

Angenommen, ein Unternehmen verteilt eingehende Anfragen heute über Postfach, Tabellen und ein CRM. Die Idee ist eine kleine Übersicht, die offene Vorgänge zusammenführt. Für den ersten Prototyp wird nur ein Anfragekanal betrachtet. Sichtbar sind Eingang, zugeordneter Kunde, fehlende Angaben und nächster Bearbeitungsschritt.

Der technische Test prüft zuerst, ob das CRM die erforderlichen Kundendaten mit dem vorgesehenen Zugang liefert. Anschließend verarbeitet der Prototyp vorbereitete Beispielanfragen. Eine Mitarbeiterin oder ein Mitarbeiter soll einen eindeutigen Fall zuordnen, einen unklaren Treffer markieren und eine Rückfrage dokumentieren. Beobachtet wird, ob die Oberfläche diese Aufgaben ohne zusätzliche Erklärung unterstützt.

Erst danach wird entschieden, ob die nächste Stufe eine echte Aufgabenübergabe erhält. Automatische Nachrichten und zusätzliche Eingangskanäle bleiben spätere Erweiterungen. Dieses hypothetische Szenario behauptet keine erzielten Einsparungen. Sein Ergebnis wäre zunächst eine überprüfte Arbeitsweise samt Liste offener fachlicher und technischer Fragen.

So werten Sie einen Prototyp sinnvoll aus

Bitten Sie Anwender, konkrete Aufgaben zu erledigen, statt nur nach ihrer allgemeinen Meinung zu fragen. Notieren Sie, wo sie suchen, zurückgehen oder Informationen vermissen. Unterscheiden Sie dabei Bedienprobleme von fehlenden Prozessregeln. Eine unklare Zuständigkeit lässt sich nicht allein durch einen anders gestalteten Button lösen.

Vergleichen Sie die Ergebnisse mit dem Anforderungsblatt. Wurde die kritische Annahme bestätigt, widerlegt oder nur teilweise geprüft? Dokumentieren Sie auch negative Erkenntnisse. Ein früh erkannter ungeeigneter Ansatz ist ein brauchbares Ergebnis, wenn er eine größere Fehlentwicklung verhindert und die nächste Entscheidung erleichtert.

Vom Prototyp zur produktiven Lösung

Vor einem produktiven Einsatz brauchen Sie unter anderem passende Zugriffsrechte, verlässliche Speicherung, Fehlerbehandlung, Datensicherung und ein nachvollziehbares Updateverfahren. Welche Teile des Prototyps übernommen werden können, muss technisch geprüft werden. Häufig bleibt die erprobte Bedienidee bestehen, während einzelne technische Abkürzungen ersetzt werden.

Bei eng begrenztem Umfang kann sich an einen Prototyp in Tagen eine erste produktive Stufe innerhalb von Wochen anschließen. Fehlende Schnittstellen, Datenmigrationen und komplexe Rollen können daraus ein deutlich längeres Vorhaben machen. Der Vorteil kleiner Schritte besteht darin, früh zu lernen, statt den ersten Realitätscheck bis zum Ende eines Programms über Monate oder Jahre aufzuschieben.

Ihre Idee in einen prüfbaren ersten Schritt übersetzen

Eine individuelle Lösung sollte Ihren Prozess treffen und vorhandene Systeme sinnvoll nutzen. Informationen zur Umsetzung finden Sie in der Projektentwicklung. Für wiederkehrende Übergaben ist Automatisierung und KI relevant; wenn die Idee auf Ihrer Website beginnt, kann eine WordPress-Erweiterung der passende Einstieg sein.

Beschreiben Sie mir Ihre Idee mit einem konkreten Arbeitsbeispiel. Nennen Sie die wichtigste offene Frage, vorhandene Systeme und die Person, die den Prototyp testen würde. So lässt sich ein erster Umfang mit nachvollziehbaren Voraussetzungen und einem realistischen Zeitrahmen bestimmen.

Weiterführende Quellen

• GOV.UK Service Manual: Prototypen erstellen und testen
• GOV.UK Service Manual: Kritische Annahmen in der Alpha-Phase prüfen

Patrick Hofmann

Individuelle Automatisierung, KI-Integration und Entwicklung. Mehr über die Zusammenarbeit.