Die möglicherweise entscheidende Unsicherheit finden
Ein PoC ist besonders hilfreich, wenn eine unklare Fähigkeit eure Entscheidung über das weitere Vorgehen verändern könnte. Können zwei Systeme die benötigten Informationen austauschen? Hält ein Material die vorgesehene Behandlung aus? Lassen sich Dokumente in den tatsächlich eingehenden Formaten verarbeiten? Benenne diese Unsicherheit, bevor du die gewünschte Vorführung planst oder ein Werkzeug auswählst.
Die Frage muss eng genug sein, um beantwortet werden zu können. „Können wir das Büro automatisieren?“ umfasst zu viele verschiedene Probleme. „Lässt sich die Bestellnummer aus unseren relevanten Dokumentformaten auslesen und dem richtigen Vorgang zuordnen?“ bietet einen klareren Startpunkt. Gleichzeitig wird leichter erkennbar, welche anderen Fragen in diesem Versuch bewusst nicht geklärt werden.
Bedingungen und Kriterien vorab bestimmen
Beschreibe Eingaben, Umgebung, erwartetes Verhalten und Grenzen vor dem Versuch. Nimm schwierige Fälle auf, die zum tatsächlichen Problem gehören. Ein Ergebnis mit idealen Eingaben kann grundsätzliche Möglichkeit zeigen, sagt aber möglicherweise wenig über euren Alltag aus. Benenne eine solche Aussage entsprechend eng, statt ihre Bedeutung nachträglich auf alle denkbaren Situationen auszudehnen.
Lege fest, welche Beobachtungen für weitere Arbeit sprechen, welche den Ansatz infrage stellen und wann die Antwort offen bleibt. Sind Zahlen nötig, sollten Grenzwerte aus dem vorgesehenen Einsatz folgen. Erfinde keinen allgemeinen Leistungsmaßstab. Wichtig ist, dass Kriterien schon bestehen, bevor das Team ein Ergebnis sieht, das es gerne als Erfolg darstellen möchte.
Ein Beispiel für die Übertragung von Bestellungen
Ein fiktiver Großhandel prüft eine Verbindung zwischen Onlinebestellungen und seinem Bestandssystem. Unklar ist, ob das ältere System die benötigten Angaben übernehmen kann, ohne Artikelbezüge zu verlieren. Ein PoC überträgt vorbereitete Beispielbestellungen in eine getrennte Testumgebung. Anschließend vergleicht das Team die entstandenen Einträge mit den zuvor festgelegten erwarteten Informationen und Zuordnungen.
Zu den Beispielen gehören ein nicht verfügbarer Artikel, eine geänderte Menge und eine wiederholte Übermittlung. Geprüft werden normaler Transfer und Umgang mit diesen Fällen. Ein gutes Ergebnis stützt den Ansatz unter den untersuchten Bedingungen. Es belegt noch keine vollständige Betriebsbereitschaft, Sicherheit, Belastbarkeit bei Spitzenlast oder Nützlichkeit des gesamten Bestelldienstes für Kunden und Beschäftigte.
Die Untersuchung kleiner als das Projekt halten
Konzentriere dich auf den unsicheren Teil, statt bereits eine vollständige Bedienoberfläche darum zu bauen. Ein einfaches Skript oder eine manuelle Beobachtung kann eine technische Frage ausreichend beantworten. Zusätzliche Gestaltung verbraucht Zeit und lässt die Vorführung womöglich fertiger wirken, als ihre Aussagekraft rechtfertigt. Halte sichtbar fest, welche Bestandteile absichtlich noch nicht vorhanden sind.
Ein Prototyp kann Teil der Untersuchung sein, wenn Bedienung oder Form eine Rolle spielen. Beide Begriffe beschreiben jedoch unterschiedliche Zwecke: Der Prototyp macht eine Idee untersuchbar, der PoC konzentriert sich auf Machbarkeit. Erkläre deshalb Frage und Vorgehen konkret, statt davon auszugehen, dass die Bezeichnung allen Beteiligten schon sagt, was tatsächlich überprüft wurde.
Nicht nur den einfachen Fall betrachten
Nachdem ein normaler Vorgang funktioniert hat, prüfe die Bedingungen, die den Ansatz am ehesten scheitern lassen könnten. Bei einer API gehören dazu möglicherweise fehlende Felder, geänderte Kennungen, Unterbrechungen und wiederholte Anfragen. Welche Fälle wichtig sind, folgt aus dem geplanten Einsatz. Ihr braucht nicht jeden späteren Produktionstest, aber die schwierigen Bedingungen eurer zentralen Unsicherheit.
Dokumentiere Fehlschläge sorgfältig. Ein misslungener Versuch kann eine fehlende Annahme, einen ungeeigneten Ansatz oder eine weitere zu untersuchende Grenze aufdecken. Ändere Eingaben nicht stillschweigend so lange, bis die Vorführung klappt. Wenn ein Fall vereinfacht wird, halte fest, was sich geändert hat und dass sich die Schlussfolgerung nun auf diese engere Bedingung bezieht.
Nachvollziehbare Hinweise statt nur Bilder sammeln
Halte Frage, Aufbau, Eingaben, Schritte, Beobachtungen und Schlussfolgerung zusammen. Versionsstände oder Einstellungen gehören dazu, wenn sie das Ergebnis beeinflussen. Ein Bildschirmbild kann den Bericht ergänzen. Ein hübsches Bild einer Erfolgsmeldung reicht aber nicht aus, um zu verstehen, was passiert ist und ob eine andere Person den Versuch unter denselben Bedingungen wiederholen könnte.
Trenne Ergebnis und Empfehlung. „Diese Beispielbestellungen wurden korrekt übertragen“ beschreibt einen Befund. „Wir sollten das gesamte System ersetzen“ ist eine wesentlich größere Entscheidung. Eine Empfehlung sollte deshalb offene Unsicherheiten, Alternativen und nötige Folgearbeiten erklären. So kann die verantwortliche Person die Bedeutung einschätzen, ohne Begeisterung für den Ansatz mit Vollständigkeit der Prüfung zu verwechseln.
Nach dem Versuch bewusst weiterentscheiden
Der nächste Schritt kann ein breiterer Test, ein anderer Ansatz, ein begrenztes nutzbares Angebot oder der Verzicht auf weitere Arbeit sein. Entscheide nach Ergebnis und Bedeutung der verbleibenden Fragen. Technische Machbarkeit allein bedeutet noch nicht, dass die Lösung betrieblich sinnvoll ist. Vielleicht erzeugt sie zu viel Zusatzarbeit oder löst gar kein wichtiges Kundenproblem.
Wenn ihr weitermacht, benennt die fehlenden Voraussetzungen für den Alltag. Fehlerbehandlung, Rechte, Überwachung, Wartung und Unterstützung können noch vollständig offen sein. Ein PoC ist häufig vorläufige Arbeit. Seine Weiterverwendung kann sinnvoll sein, braucht aber eine ausdrückliche Prüfung. Aus demonstrierter Möglichkeit sollte nicht unbemerkt die Annahme werden, dass damit bereits der ganze Betrieb arbeiten kann.
Ein kleiner Auftrag für deinen PoC
Schreibe eine Hauptfrage, relevante Bedingungen, benötigte Eingaben, vereinbarte Kriterien und einen Endpunkt auf. Ergänze, welche Entscheidung das Ergebnis unterstützen soll und welche Aussagen es nicht erlaubt. Benenne auch, wer die Hinweise bewertet. Hilfreich ist ausreichend Abstand zur bevorzugten Lösung, damit eine optimistische Deutung im Zweifel sachlich hinterfragt werden kann, ohne einen persönlichen Konflikt auszulösen.
Formuliere am Ende eine begrenzte Schlussfolgerung: unter den geprüften Bedingungen machbar, mit diesem Ansatz nicht machbar oder weiterhin ungeklärt. Begründe sie und benenne die nächste wichtige Unsicherheit. Auch ein sauber erklärtes negatives Ergebnis kann wertvoll sein, wenn es eine größere Fehlentscheidung verhindert. Ziel ist eine bessere Entscheidung und nicht eine um jeden Preis erfolgreiche Vorführung.
Häufige Fragen
Beweist ein erfolgreicher PoC, dass das Projekt funktioniert?
Nein. Er stützt eine konkrete Fähigkeit unter den untersuchten Bedingungen. Ein vollständiges Vorhaben hängt zusätzlich von Nutzern, Betrieb, Kosten, Schnittstellen und weiteren Anforderungen ab. Halte diese Fragen auseinander und entscheide, welche vor einer größeren Zusage noch geprüft werden müssen.
Wie lange sollte ein PoC dauern?
Setze eine Grenze, die zur Frage und zum Wert ihrer Klärung passt. Eine allgemeingültige Dauer gibt es nicht. Wächst die Untersuchung ständig, kehre zur ursprünglichen Unsicherheit zurück. Trenne zusätzliche Fragen, statt den PoC stillschweigend in das vollständige Projekt zu verwandeln.