Proof of Concept
Ein Wegwerf-Build, der eine Frage beantwortet: ist das technisch möglich. Kein Produkt, kein MVP, nichts, was du an Nutzer ausspielst.
Ein Proof of Concept existiert, um genau ein technisches Risiko auszuräumen. Schafft dieses Modell die nötige Latenz. Funktioniert diese Integration wirklich gegen das Altsystem. Können wir die Kryptografie beweisen, bevor wir ein Produkt darum herum entwerfen. Ein PoC beantwortet „ist das möglich" und sonst nichts. Er wird schnell gebaut, danach beurteilt, ob er funktioniert, und dann weggeworfen.
Die Unterscheidung, die Unternehmen am meisten kostet, ist PoC gegen MVP gegen Prototyp. Ein PoC beantwortet „ist das technisch möglich" und richtet sich an dein eigenes Team. Ein Prototyp beantwortet „fühlt sich das richtig an" und richtet sich an Design und Usability, oft ganz ohne echtes Backend. Ein MVP beantwortet „wird das wirklich jemand nutzen und dafür zahlen" und ist ein echtes Produkt, ausgespielt an echte Nutzer, nur auf die kleinste lohnende Version zugeschnitten. Sie haben unterschiedliche Zielgruppen, unterschiedliche Qualitätsmaßstäbe und unterschiedliche Definitionen von „fertig".
Der häufige und teure Fehler ist, einen PoC auszuspielen, als wäre er Produktion. Der Code, der bewiesen hat, dass etwas möglich ist, wurde geschrieben, um zu beweisen, dass etwas möglich ist: keine Fehlerbehandlung, keine Tests, kein Security-Review, überall Abkürzungen. Wenn der Demo jemanden beeindruckt und entschieden wird, „das einfach auszuliefern", erbst du all das als dein Fundament. Der ehrliche Zug ist, den PoC als Antwort auf eine Frage zu behandeln und dann das echte Ding sauber zu bauen.
Ein Weg, diese Disziplin unter Druck zu halten: Schreib die eine Frage auf, die der PoC beantworten soll, bevor du startest, samt Kriterien für ein Ja oder Nein. „Kann dieses Modell Support-Tickets mit 90% Genauigkeit auf unseren letzten 500 Tickets klassifizieren" ist eine Frage mit klarem Urteil. Ohne diese aufgeschriebene Frage mutiert ein PoC still zum Halbprodukt, das Team poliert weiter, weil er „fast funktioniert", und du bist ins Bauen einer V1 auf Wegwerf-Fundamenten gerutscht, ohne dass es jemand entschieden hätte. Die aufgeschriebene Frage schützt dich auch vor dem Sunk-Cost-Sog, den Wegwerf-Code doch auszuliefern: Ist die Frage beantwortet, hat der PoC seine Aufgabe erfüllt und seine Löschung verdient, egal wie schön der Demo aussah.
Wavect baut einen PoC, wenn es ein echtes technisches Risiko gibt, das sich vor der Festlegung auf einen Build auszuräumen lohnt. Die meisten Projekte brauchen keinen; sie brauchen eine Discovery-Phase , die die Arbeit scoped. Wir sagen dir, welcher Fall vorliegt.